home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_5_14.tro < prev    next >
Text File  |  1991-12-22  |  153KB  |  5,589 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 1P
  23. .ce 1000
  24. \v'3P'
  25. SECTION\ 4
  26. .ce 0
  27. .sp 1P
  28. .ce 1000
  29. \fBCONFORMANCE\ TESTING\fR \v'1P'
  30. .ce 0
  31. .sp 1P
  32. .sp 2P
  33. .LP
  34. \fBRecommendation X.290\fR 
  35. .RT
  36. .sp 2P
  37. .ce 1000
  38. \fBOSI\ CONFORMANCE\ TESTING\ METHODOLOGY\ AND\ FRAMEWORK\ FOR\fR 
  39. .EF '%    Fascicle\ VIII.5\ \(em\ Rec.\ X.290''
  40. .OF '''Fascicle\ VIII.5\ \(em\ Rec.\ X.290    %'
  41. .ce 0
  42. .sp 1P
  43. .ce 1000
  44. \fBPROTOCOL\ RECOMMENDATIONS\ FOR\ CCITT\ APPLICATIONS\fR 
  45. .FS
  46. Recommendation\ X.290 was developed in close collaboration with the ISO/IEC 
  47. effort on OSI Conformance Testing Methodology and Framework. At the time 
  48. of publication, 
  49. Recommendation\ X.290 was aligned with the texts of DP\ 9646/1 and DP\ 9646/2.
  50. Since this work was at an early stage of development, changes should be
  51. expected. Consequently, users should exercise caution in applying this
  52. Recommendation.
  53. .FE
  54. .ce 0
  55. .sp 1P
  56. .ce 1000
  57. \fI(Melbourne, 1988)\fR 
  58. .sp 9p
  59. .RT
  60. .ce 0
  61. .sp 1P
  62. .LP
  63.     The\ CCITT,
  64. .sp 1P
  65. .RT
  66. .sp 2P
  67. .LP
  68. \fIconsidering\fR 
  69. .sp 1P
  70. .RT
  71. .PP
  72. (a)
  73. that Recommendation X.200 defines the Reference Model of Open Systems for 
  74. CCITT Applications; 
  75. .PP
  76. (b)
  77. that the objective of OSI will not be completely
  78. achieved until systems dedicated to CCITT applications can be tested to
  79. determine whether they conform to the relevant OSI protocol Recommendations;
  80. .PP
  81. (c)
  82. that standardized test suites should be developed for
  83. each OSI protocol Recommendation as a means to:
  84. .LP
  85.     \(em
  86.     obtain wide acceptance and confidence in conformance test
  87. results produced by different testers,
  88. .LP
  89.     \(em
  90.     provide confidence in the interoperability of equipments
  91. which passed the standardized conformance
  92. tests;
  93. .PP
  94. (d)
  95. the need for defining an international Recommendation to specify the framework 
  96. and general principles for the specification of 
  97. conformance test suites and the testing of protocol implementations,
  98. .sp 2P
  99. .LP
  100. \fIunanimously recommends\fR 
  101. .sp 1P
  102. .RT
  103. .PP
  104. (1)
  105. that the general principles, definition of terms and
  106. concepts of OSI protocol conformance testing shall be in accordance with 
  107. Part\ 1 of this Recommendation; 
  108. .PP
  109. (2)
  110. that the test methods, test suites and test notation
  111. shall be in accordance with Part\ 2 of this Recommendation.
  112. .LP
  113. .sp 3
  114. .bp
  115. .sp 1P
  116. .ce 1000
  117. CONTENTS
  118. .ce 0
  119. .sp 1P
  120. .sp 2P
  121. .LP
  122. \fBPart\ 1\fR \ \(em\ \fBGeneral concepts\fR 
  123. .sp 1P
  124. .RT
  125. .sp 1P
  126. .LP
  127. 0
  128.     Introduction
  129. .sp 9p
  130. .RT
  131. .LP
  132. 1
  133.     Scope and field of application
  134. .LP
  135. 2
  136.     References
  137. .sp 2P
  138. .LP
  139. SECTION\ 1\ \(em
  140.     \fITerminology\fR 
  141. .sp 1P
  142. .RT
  143. .sp 1P
  144. .LP
  145. 3
  146.     Definitions
  147. .sp 9p
  148. .RT
  149. .LP
  150. 4
  151.     Abbreviations
  152. .sp 2P
  153. .LP
  154. SECTION\ 2\ \(em
  155.     \fIOverview\fR 
  156. .sp 1P
  157. .RT
  158. .sp 1P
  159. .LP
  160. 5
  161.     The meaning of conformance in OSI*
  162. .sp 9p
  163. .RT
  164. .LP
  165. 6
  166.     Conformance and testing
  167. .LP
  168. 7
  169.     Test methods
  170. .LP
  171. 8
  172.     Test suites
  173. .LP
  174. 9
  175.     Relationships between, concepts and roles
  176. .LP
  177. 10
  178.     Compliance
  179. .LP
  180. \fBPart\ 2\fR \ \(em\ \fBAbstract test suite specification\fR 
  181. .sp 1P
  182. .RT
  183. .sp 1P
  184. .LP
  185. 0
  186.     Introduction
  187. .sp 9p
  188. .RT
  189. .LP
  190. 1
  191.     Scope and field of application
  192. .LP
  193. 2
  194.     References
  195. .LP
  196. 3
  197.     Definitions
  198. .LP
  199. 4
  200.     Abbreviations
  201. .LP
  202. 5
  203.     Compliance
  204. .sp 2P
  205. .LP
  206. SECTION\ 1\ \(em
  207.     \fIRequirements on protocol specifiers\fR 
  208. .sp 1P
  209. .RT
  210. .sp 1P
  211. .LP
  212. 6
  213.     Conformance requirements in OSI* Recommendations*
  214. .sp 9p
  215. .RT
  216. .LP
  217. 7
  218.     PICS proformas
  219. .sp 2P
  220. .LP
  221. SECTION\ 2\ \(em
  222.     \fIRequirements on abstract test suite specifiers\fR 
  223. .sp 1P
  224. .RT
  225. .sp 1P
  226. .LP
  227. 8
  228.     Test suite production process
  229. .sp 9p
  230. .RT
  231. .LP
  232. 9
  233.     Determining the conformance requirements and PICS
  234. .LP
  235. 10
  236.     Test suite structure
  237. .LP
  238. 11
  239.     Generic test case specification
  240. .LP
  241. 12
  242.     Abstract test methods
  243. .LP
  244. 13
  245.     Specification of abstract test suites
  246. .LP
  247. 14
  248.     Use of an abstract test suite specification
  249. .LP
  250. 15
  251.     Test suite maintenance
  252. .sp 1P
  253. .LP
  254. \fIAnnex\ A\fR     \(em
  255.     Options
  256. .sp 9p
  257. .RT
  258. .LP
  259. \fIAnnex\ B\fR     \(em
  260.     Guidance for protocol Recommendations* writers
  261. .LP
  262. \fIAnnex\ C\fR     \(em
  263.     Incomplete static conformance requirements
  264. .LP
  265. \fIAnnex\ D\fR     \(em
  266.     Tree and tabular combined notation
  267. .sp 1P
  268. .LP
  269. \fIAppendix\ I\fR     \(em
  270.     Applicability of the test methods to
  271. OSI* protocols
  272. .sp 9p
  273. .RT
  274. .LP
  275. \fIAppendix\ II\fR 
  276.     \(em
  277.     Index to definitions of terms
  278. .LP
  279. \fIAppendix\ III\fR     \(em
  280.     Examples for guidance for PICS proforma
  281. .LP
  282. \fIAppendix\ IV\fR 
  283.     \(em
  284.     Example of choice of abstract
  285. test methods
  286. .bp
  287. .sp 1P
  288. .ce 1000
  289. \fBPart\ 1\ \(em\ General concepts\fR 
  290. .sp 1P
  291. .RT
  292. .ce 0
  293. .sp 1P
  294. .sp 2P
  295. .LP
  296. \fB0\fR     \fBIntroduction\fR 
  297. .sp 1P
  298. .RT
  299. .PP
  300. The objective of OSI will not be completely achieved until systems can 
  301. be tested to determine whether they conform to the relevant \*QOSI or related 
  302. CCITT X\(hyseries or T\(hyseries\*U (hereafter abbreviated to \*QOSI*\*U) 
  303. protocol 
  304. \*Qstandard(s) or Recommendation(s)\*U (hereafter abbreviated to
  305. \*QRecommendation(s)*\*U).
  306. .PP
  307. Standardized test suites should be developed for each OSI*
  308. protocol Recommendation, for use by suppliers or implementors in self\(hytesting, 
  309. by users of OSI products, by the Administrations* or other third party 
  310. testers. This should lead to comparability and wide acceptance of test 
  311. results produced by different testers, and thereby minimize the need for 
  312. repeated 
  313. conformance testing of the same system.
  314. .PP
  315. The standardization of test suites requires international
  316. definition and acceptance of a common testing methodology and appropriate
  317. testing methods and procedures. It is the purpose of this Recommendation to
  318. define the methodology, to provide a framework for specifying conformance 
  319. test suites and define the procedures to be followed during testing. 
  320. .PP
  321. Conformance testing involves testing both the capabilities and
  322. behaviour of an implementation and checking what is observed against the
  323. conformance requirements in the relevant Recommendation(s)* and against
  324. what the implementor states the implementation's capabilities are.
  325. .PP
  326. Conformance testing does not include assessment of the performance
  327. nor the robustness or reliability of an implementation. It cannot give
  328. judgements on the physical realization of the abstract service primitives, 
  329. how a system is implemented, how it provides any requested service, nor 
  330. the 
  331. environment of the protocol implementation. It cannot, except in an indirect
  332. way, prove anything about the logical design of the protocol itself.
  333. .PP
  334. The purpose of conformance testing is to increase the probability that 
  335. different implementations are able to interwork. This is achieved by verifying 
  336. them by means of a protocol test suite, thereby increasing the confidence 
  337. that each implementation conforms to the protocol specification. Confidence 
  338. in 
  339. conformance to a protocol specification is particularly important when
  340. equipment supplied by different vendors is required to interwork.
  341. .PP
  342. However, it should be borne in mind that the complexity of most
  343. protocols makes exhaustive testing impractical on both technical and economic 
  344. grounds. Also, testing cannot guarantee conformance to a specification 
  345. since it detects errors rather than their absence. Thus conformance to 
  346. a test suite 
  347. alone cannot guarantee interworking. What it does do is give confidence 
  348. that an implementation has the required capabilities and that its behaviour 
  349. conforms 
  350. consistently in representative instances of communication.
  351. .PP
  352. It should be noted that the OSI reference model for CCITT
  353. applications (Recommendation\ X.200) states (in \(sc\ 4.3):
  354. .RT
  355. .LP
  356.     \*QOnly the external behaviour of Open Systems is
  357. retained as the standard of behaviour of real Open
  358. Systems\*U.
  359. .PP
  360. This means that although aspects of both internal and external
  361. behaviour are described in OSI* Recommendations*, only the requirements on
  362. external behaviour have to be met by real open systems. Although some of the
  363. methods defined in this Recommendation do impose certain constraints on the
  364. implementor, for example that there be some means of realizing control and
  365. observation at one or more service access points, it should be noted that 
  366. other methods defined herein do not impose such constraints. 
  367. .PP
  368. However, in the case of partial OSI* end\(hysystems which
  369. provide OSI* protocols up to a specific layer boundary, it is desirable
  370. to test both the external behaviour of the implemented protocol entities and
  371. the potential of those entities for supporting correct external behaviour in
  372. higher layers.
  373. .PP
  374. Detailed investigation of relative benefits, efficiency and
  375. constraints of all methods is addressed in various parts of this
  376. Recommendation. However, any organization contemplating the use of test 
  377. methods defined in this Recommendation in a context such as certification 
  378. should 
  379. carefully consider the constraints on applicability and the benefits of the
  380. different possible test methods.
  381. .PP
  382. Testing is voluntary as far as ISO/CCITT is concerned. Requirements
  383. for testing in procurement and other external contracts are not a matter for
  384. standardization.
  385. .bp
  386. .RT
  387. .sp 2P
  388. .LP
  389. \fB1\fR     \fBScope and field of application\fR 
  390. .sp 1P
  391. .RT
  392. .PP
  393. 1.1
  394. This Recommendation specifies a general methodology for testing the conformance 
  395. to OSI* protocol Recommendation(s)* of products 
  396. in which the Recommendation(s)* are claimed to be implemented. The
  397. methodology also applies to testing conformance to transfer syntax
  398. Recommendation(s)* to the extent that can be determined by testing each in
  399. combination with a specific OSI* protocol.
  400. .sp 9p
  401. .RT
  402. .PP
  403. 1.2
  404. This Recommendation is structured into two separate
  405. parts:
  406. .sp 9p
  407. .RT
  408. .PP
  409. \fIPart\ 1\fR \|identifies the different phases of conformance testing 
  410. process, these phases being characterized by four major roles. These roles 
  411. are:
  412. .LP
  413.     a)
  414.     the specification of abstract test suites for particular
  415. OSI* protocols;
  416. .LP
  417.     b)
  418.     the derivation of executable test suites and associated
  419. testing tools;
  420. .LP
  421.     c)
  422.     the role of a client of a test laboratory, having an
  423. implementation of OSI* protocols to be tested;
  424. .LP
  425.     d)
  426.     the operation of conformance testing, culminating in the
  427. production of a conformance test report which gives the results
  428. in terms of the Recommendation(s)* and the test suite(s)
  429. used.
  430. .PP
  431. Additionally, this Part provides tutorial material, together with definition 
  432. of concepts and terms. 
  433. .PP
  434. \fIPart\ 2\fR \| defines the requirements and guidance for the
  435. specification of abstract test suites for OSI* protocols.
  436. .RT
  437. .PP
  438. 1.3
  439. In both Parts of this Recommendation, the scope is limited to include only 
  440. such information as is necessary to meet the following 
  441. objectives:
  442. .sp 9p
  443. .RT
  444. .LP
  445.     a)
  446.      to achieve an adequate level of confidence in the tests as a guide to 
  447. conformance; 
  448. .LP
  449.     b)
  450.     to achieve comparability between the results of the
  451. corresponding tests applied in different places at different
  452. times;
  453. .LP
  454.     c)
  455.      to facilitate communication between the parties responsible for the roles 
  456. described above. 
  457. .PP
  458. 1.4
  459. One such aspect of this scope involves the framework for
  460. development of OSI* test suites. For example:
  461. .sp 9p
  462. .RT
  463. .LP
  464.     a)
  465.     how they should relate to the various types of conformance
  466. requirement;
  467. .LP
  468.     b)
  469.     the types of test to be standardized and the types not
  470. needing standardization;
  471. .LP
  472.     c)
  473.     the criteria for selecting tests for inclusion in a
  474. conformance test suite;
  475. .LP
  476.     d)
  477.     the notation to be used for defining tests;
  478. .LP
  479.     e)
  480.     the structure of a test suite.
  481. .PP
  482. 1.5
  483. Certification, an administrative procedure which may follow
  484. conformance testing, is outside the scope of this Recommendation. Requirements 
  485. for procurement and contracts are also outside the scope of this 
  486. Recommendation.
  487. .sp 9p
  488. .RT
  489. .PP
  490. 1.6
  491. The Physical layer and Media Access Control protocols are
  492. outside the field of application of this Recommendation.
  493. .sp 9p
  494. .RT
  495. .sp 2P
  496. .LP
  497. \fB2\fR     \fBReferences\fR 
  498. .sp 1P
  499. .RT
  500. .sp 1P
  501. .LP
  502. Recommendation\ X.200\ \(em
  503.     \fIReference model of open systems\fR 
  504. \fIinterconnection for CCITT applications\fR \|
  505. (see also ISO\ 7498).
  506. .sp 9p
  507. .RT
  508. .LP
  509. Recommendation\ X.210\ \(em
  510.     \fIOpen systems interconnection layer\fR 
  511. \fIservice definition conventions\fR \|
  512. (see also ISO TR\ 8509).
  513. .LP
  514. Recommendation\ X.209\ \(em
  515.     \fISpecification of basic encoding rules for\fR 
  516. \fIabstract syntax notation one (ASN.1)\fR \|
  517. (see also ISO\ 8825).
  518. .LP
  519. .rs
  520. .sp 2P
  521. .ad r
  522. BLANC
  523. .ad b
  524. .RT
  525. .LP
  526. .bp
  527. .sp 1P
  528. .ce 1000
  529. SECTION\ 1\ \(em\ \fITerminology\fR 
  530. .sp 1P
  531. .RT
  532. .ce 0
  533. .sp 1P
  534. .sp 2P
  535. .LP
  536. \fB3\fR     \fBDefinitions\fR 
  537. .sp 1P
  538. .RT
  539. .sp 1P
  540. .LP
  541. 3.1
  542.     \fIReference model definitions\fR 
  543. .sp 9p
  544. .RT
  545. .PP
  546. This Recommendation is based upon the concepts developed in
  547. reference model of open systems interconnection for CCITT applications 
  548. (CCITT X.200), and makes use of the following terms defined in that 
  549. Recommendation:
  550. .RT
  551. .LP
  552.     a)
  553.     (N)\(hyentity
  554. .LP
  555.     b)
  556.     (N)\(hyservice
  557. .LP
  558.     c)
  559.     (N)\(hylayer
  560. .LP
  561.     d)
  562.     (N)\(hyprotocol
  563. .LP
  564.     e)
  565.     (N)\(hyservice\(hyaccess\(hypoint
  566. .LP
  567.     f
  568. )
  569.     (N)\(hyrelay
  570. .LP
  571.     g)
  572.     (N)\(hyprotocol\(hydata\(hyunit
  573. .LP
  574.     h)
  575.     (N)\(hyprotocol\(hycontrol\(hyinformation
  576. .LP
  577.     i)
  578.     (N)\(hyuser\(hydata
  579. .LP
  580.     j)
  581.     real open system
  582. .LP
  583.     k)
  584.     subnetwork
  585. .LP
  586.     l)
  587.     application\(hyentity
  588. .LP
  589.     m)
  590.     application\(hyservice\(hyelement
  591. .LP
  592.     n)
  593.     transfer syntax
  594. .LP
  595.     o)
  596.     physical layer
  597. .LP
  598.     p)
  599.     data link layer
  600. .LP
  601.     q)
  602.     network layer
  603. .LP
  604.     r)
  605.     transport layer
  606. .LP
  607.     s)
  608.     session layer
  609. .LP
  610.     t)
  611.     presentation layer
  612. .LP
  613.     u)
  614.     application layer
  615. .LP
  616.     v)
  617.     systems\(hymanagement
  618. .LP
  619.     w)
  620.     application\(hymanagement
  621. .LP
  622.     x)
  623.     layer\(hymanagement
  624. .sp 1P
  625. .LP
  626. 3.2
  627.     \fITerms defined in other Recommendations\fR 
  628. .sp 9p
  629. .RT
  630. .PP
  631. This Recommendation uses the following terms defined in the OSI
  632. Service Conventions (Recommendation\ X.210):
  633. .RT
  634. .LP
  635.     a)
  636.     service\(hyuser
  637. .LP
  638.     b)
  639.     service\(hyprovider
  640. .PP
  641. This Recommendation uses the following term defined in the ASN.1\ \(em 
  642. Basic Encoding Rules Recommendation (Recommendation\ X.209): 
  643. .LP
  644.     c)
  645.     encoding
  646. .sp 1P
  647. .LP
  648. 3.3
  649.     \fIConformance testing definitions\fR 
  650. .sp 9p
  651. .RT
  652. .PP
  653. For the purposes of this Recommendation the definitions in \(sc\(sc 3.4 
  654. to 3.8 apply. 
  655. .RT
  656. .sp 2P
  657. .LP
  658. 3.4
  659.     \fIBasic terms\fR 
  660. .sp 1P
  661. .RT
  662. .sp 1P
  663. .LP
  664. 3.4.1
  665.     \fBimplementation under test (IUT)\fR 
  666. .sp 9p
  667. .RT
  668. .PP
  669. That part of a real open system which is to be studied by testing, which 
  670. should be an implementation of one or more OSI* protocols in an adjacent 
  671. user/provider relationship. 
  672. .bp
  673. .RT
  674. .sp 1P
  675. .LP
  676. 3.4.2
  677.     \fBsystem under test (SUT)\fR 
  678. .sp 9p
  679. .RT
  680. .PP
  681. The real open system in which the IUT resides.
  682. .RT
  683. .sp 1P
  684. .LP
  685. 3.4.3
  686.     \fBdynamic conformance requirements\fR 
  687. .sp 9p
  688. .RT
  689. .PP
  690. All those requirements (and options) which determine what
  691. observable behaviour is permitted by the relevant OSI* Recommendation(s)* in
  692. instances of communication.
  693. .RT
  694. .sp 1P
  695. .LP
  696. 3.4.4
  697.     \fBstatic conformance requirements\fR 
  698. .sp 9p
  699. .RT
  700. .PP
  701. Constraints which are placed in OSI* Recommendations* to
  702. facilitate interworking by defining the requirements for the capabilities 
  703. of an implementation. 
  704. .PP
  705. \fINote\fR \ \(em\ Static conformance requirements may be at a broad level, 
  706. such as the grouping of functional units and options into protocol classes, 
  707. or at a detailed level, such as the ranges of values that are to be supported 
  708. for 
  709. specific parameters or timers.
  710. .RT
  711. .sp 1P
  712. .LP
  713. 3.4.5
  714.     \fBcapabilities of an IUT\fR 
  715. .sp 9p
  716. .RT
  717. .PP
  718. That set of functions and options in the relevant protocol(s) and, if appropriate, 
  719. that set of facilities and options of the relevant service 
  720. definition which are supported by the IUT.
  721. .RT
  722. .sp 1P
  723. .LP
  724. 3.4.6
  725.     \fBprotocol implementation conformance statement (PICS)\fR 
  726. .sp 9p
  727. .RT
  728. .PP
  729. A statement made by the supplier of an OSI* implementation or
  730. system, stating the capabilities and options which have been implemented, 
  731. and any features which have been omitted. 
  732. .RT
  733. .sp 1P
  734. .LP
  735. 3.4.7
  736.     \fBPICS proforma\fR 
  737. .sp 9p
  738. .RT
  739. .PP
  740. A document, in the form of a questionnaire, designed by the
  741. protocol specifier or conformance test suite specifier, which when completed
  742. for an OSI* implementation or system becomes the PICS.
  743. .RT
  744. .sp 1P
  745. .LP
  746. 3.4.8
  747.     \fBprotocol implementation extra information for testing
  748. (PIXIT)\fR 
  749. .sp 9p
  750. .RT
  751. .PP
  752. A statement made by a supplier or implementor of an IUT which
  753. contains or references all of the information (in addition to that given 
  754. in the PICS) related to the IUT and its testing environment, which will 
  755. enable the 
  756. test laboratory to run the appropriate test suite against the IUT.
  757. .RT
  758. .sp 1P
  759. .LP
  760. 3.4.9
  761.     \fBPIXIT proforma\fR 
  762. .sp 9p
  763. .RT
  764. .PP
  765. A document, in the form of a questionnaire, provided by the test laboratory, 
  766. which when completed during the preparation for testing becomes a PIXIT. 
  767. .RT
  768. .sp 1P
  769. .LP
  770. 3.4.10
  771.     \fBconforming implementation\fR 
  772. .sp 9p
  773. .RT
  774. .PP
  775. An IUT which is shown to satisfy both static and dynamic
  776. conformance requirements, consistent with the capabilities stated in the
  777. PICS.
  778. .RT
  779. .sp 1P
  780. .LP
  781. 3.4.11
  782.     \fBsystem conformance statement\fR 
  783. .sp 9p
  784. .RT
  785. .PP
  786. A document summarizing which OSI* Recommendations* are implemented and 
  787. to which conformance is claimed. 
  788. .RT
  789. .sp 1P
  790. .LP
  791. 3.4.12
  792.     \fBclient\fR 
  793. .sp 9p
  794. .RT
  795. .PP
  796. The organization that submits a system or implementation for
  797. conformance testing.
  798. .RT
  799. .sp 1P
  800. .LP
  801. 3.4.13
  802.     \fBtest laboratory\fR 
  803. .sp 9p
  804. .RT
  805. .PP
  806. An organization that carries out conformance testing. This can be a third 
  807. party, a user organization, an Administration*, or an identifiable part 
  808. of the supplier organization. 
  809. .bp
  810. .RT
  811. .sp 2P
  812. .LP
  813. 3.5
  814.     \fITypes of testing\fR 
  815. .sp 1P
  816. .RT
  817. .sp 1P
  818. .LP
  819. 3.5.1
  820.     \fBactive testing\fR 
  821. .sp 9p
  822. .RT
  823. .PP
  824. The application of a test suite to an SUT, under controlled
  825. conditions, with the intention of observing the consequent actions of the
  826. IUT.
  827. .RT
  828. .sp 1P
  829. .LP
  830. 3.5.2
  831.     \fBpassive testing\fR 
  832. .sp 9p
  833. .RT
  834. .PP
  835. The observation of PDU activity on a link, and checking
  836. whether or not the observed behaviour is allowed by the relevant
  837. Recommendation(s)*.
  838. .RT
  839. .sp 1P
  840. .LP
  841. 3.5.3
  842.     \fBmulti\(hylayer testing\fR 
  843. .sp 9p
  844. .RT
  845. .PP
  846. Testing the behaviour of a multi\(hylayer IUT as a whole, rather than testing 
  847. it layer by layer. 
  848. .RT
  849. .sp 1P
  850. .LP
  851. 3.5.4
  852.     \fBembedded testing\fR 
  853. .sp 9p
  854. .RT
  855. .PP
  856. Testing the behaviour of a single layer within a multi\(hylayer IUT without 
  857. accessing the layer boundaries for that layer within the IUT. 
  858. .RT
  859. .sp 1P
  860. .LP
  861. 3.5.5
  862.     \fBbasic interconnection testing\fR 
  863. .sp 9p
  864. .RT
  865. .PP
  866. Limited testing of an IUT to determine whether or not there is
  867. sufficient conformance to the main features of the relevant protocol(s) for
  868. interconnection to be possible, without trying to perform thorough
  869. testing.
  870. .RT
  871. .sp 1P
  872. .LP
  873. 3.5.6
  874.     \fBcapability testing\fR 
  875. .sp 9p
  876. .RT
  877. .PP
  878. Testing to determine the capabilities of an IUT.
  879. .PP
  880. \fINote\fR \ \(em\ This involves checking all mandatory capabilities and 
  881. those optional ones that are stated in the PICS as being supported, but 
  882. not checking those optional ones which are stated in the PICS as not supported 
  883. by the 
  884. IUT.
  885. .RT
  886. .sp 1P
  887. .LP
  888. 3.5.7
  889.     \fBstatic conformance review\fR 
  890. .sp 9p
  891. .RT
  892. .PP
  893. A review of the extent to which the static conformance
  894. requirements are met by the IUT, by comparing the static conformance
  895. requirements expressed in the relevant Recommendation(s)* with the PICS 
  896. and the results of any associated capability testing. 
  897. .RT
  898. .sp 1P
  899. .LP
  900. 3.5.8
  901.     \fBbehaviour testing\fR 
  902. .sp 9p
  903. .RT
  904. .PP
  905. Testing the extent to which the dynamic conformance requirements are met 
  906. by the IUT. 
  907. .RT
  908. .sp 1P
  909. .LP
  910. 3.5.9
  911.     \fBconformance testing\fR 
  912. .sp 9p
  913. .RT
  914. .PP
  915. Testing the extent to which an IUT is a conforming
  916. implementation.
  917. .RT
  918. .sp 1P
  919. .LP
  920. 3.5.10
  921.     \fBconformance assessment process\fR 
  922. .sp 9p
  923. .RT
  924. .PP
  925. The complete process of accomplishing all conformance testing
  926. activities necessary to enable the conformance of an implementation or 
  927. a system to one or more OSI* Recommendations* to be assessed. It includes 
  928. the 
  929. production of the PICS and PIXIT documents, preparation of the real tester 
  930. and the SUT, the execution of one or more test suites, the analysis of 
  931. the results and the production of the appropriate system and protocol conformance 
  932. test 
  933. reports.
  934. .RT
  935. .sp 2P
  936. .LP
  937. 3.6
  938.     \fITerminology of test suites\fR 
  939. .sp 1P
  940. .RT
  941. .sp 1P
  942. .LP
  943. 3.6.1
  944.     \fBabstract test method\fR 
  945. .sp 9p
  946. .RT
  947. .PP
  948. The description of how an IUT is to be tested, given at an
  949. appropriate level of abstraction to make the description independent of any
  950. particular implementation of testing tools, but with enough detail to enable
  951. tests to be specified for this method.
  952. .bp
  953. .RT
  954. .sp 1P
  955. .LP
  956. 3.6.2
  957.     \fBabstract testing methodology\fR 
  958. .sp 9p
  959. .RT
  960. .PP
  961. An approach to describing and categorizing abstract test
  962. methods.
  963. .RT
  964. .sp 1P
  965. .LP
  966. 3.6.3
  967.     \fBabstract test case\fR 
  968. .sp 9p
  969. .RT
  970. .PP
  971. A complete and independent specification of the actions required to achieve 
  972. a specific test purpose, defined at the level of abstraction of a 
  973. particular abstract test method. It includes a preamble and a postamble to
  974. ensure starting and ending in a stable state (i.e.,\ a state which can be
  975. maintained almost indefinitely, such as the \*Qidle\*U state or \*Qdata 
  976. transfer\*U 
  977. state) and involves one or more consecutive or concurrent connections.
  978. .PP
  979. \fINote\ 1\fR \ \(em\ The specification should be complete in the sense 
  980. that it is sufficient to enable a verdict to be assigned unambiguously 
  981. to each 
  982. potentially observable outcome (i.e.,\ sequence of test events).
  983. .PP
  984. \fINote\ 2\fR \ \(em\ The specification should be independent in the sense 
  985. that it should be possible to execute the derived executable test case 
  986. in isolation from other such test cases (i.e.,\ the specification should 
  987. always include the possibility of starting and finishing in the \*Qidle\*U 
  988. state \(em\ that is without any existing connections except permanent ones). 
  989. For some test cases, there may be pre\(hyrequisites in the sense that execution 
  990. might require some specific 
  991. capabilities of the IUT, which should have been confirmed by results of the
  992. test cases executed earlier.
  993. .RT
  994. .sp 1P
  995. .LP
  996. 3.6.4
  997.     \fBexecutable test case\fR 
  998. .sp 9p
  999. .RT
  1000. .PP
  1001. A realization of an abstract test case.
  1002. .PP
  1003. \fINote\fR \ \(em\ In general the use of the word \*Qtest\*U will imply 
  1004. its normal English meaning. Sometimes it may be used as an abbreviation 
  1005. for abstract test case or executable test case. The context should make 
  1006. the meaning 
  1007. clear.
  1008. .RT
  1009. .sp 1P
  1010. .LP
  1011. 3.6.5
  1012.     \fBtest purpose\fR 
  1013. .sp 9p
  1014. .RT
  1015. .PP
  1016. A description of the objective which an abstract test case is
  1017. designed to achieve.
  1018. .RT
  1019. .sp 1P
  1020. .LP
  1021. 3.6.6
  1022.     \fBgeneric test case\fR 
  1023. .sp 9p
  1024. .RT
  1025. .PP
  1026. A specification of the actions required to achieve a specific test purpose, 
  1027. defined by a test body together with a description of the initial 
  1028. state in which the test body is to start.
  1029. .RT
  1030. .sp 1P
  1031. .LP
  1032. 3.6.7
  1033.     \fBpreamble\fR 
  1034. .sp 9p
  1035. .RT
  1036. .PP
  1037. The test steps needed to define the path from the starting stable state 
  1038. of the test case up to the initial state from which the test body will 
  1039. start.
  1040. .RT
  1041. .sp 1P
  1042. .LP
  1043. 3.6.8
  1044.     \fBtest body\fR 
  1045. .sp 9p
  1046. .RT
  1047. .PP
  1048. The set of test steps that are essential in order to achieve the test purpose 
  1049. and assign verdicts to the possible outcomes. 
  1050. .RT
  1051. .sp 1P
  1052. .LP
  1053. 3.6.9
  1054.     \fBpostamble\fR 
  1055. .sp 9p
  1056. .RT
  1057. .PP
  1058. The test steps needed to define the paths from the end of the test body 
  1059. up to the finishing stable state for the test case. 
  1060. .RT
  1061. .sp 1P
  1062. .LP
  1063. 3.6.10
  1064.     \fBtest step\fR 
  1065. .sp 9p
  1066. .RT
  1067. .PP
  1068. A named subdivision of a test case, constructed from test events and/or 
  1069. other test steps, and used to modularize abstract test cases. 
  1070. .RT
  1071. .sp 1P
  1072. .LP
  1073. 3.6.11
  1074.     \fBtest event\fR 
  1075. .sp 9p
  1076. .RT
  1077. .PP
  1078. An indivisible unit of test specification at the level of
  1079. abstraction of the specification (e.g.,\ sending or receiving a single
  1080. PDU).
  1081. .bp
  1082. .RT
  1083. .sp 1P
  1084. .LP
  1085. 3.6.12
  1086.     \fBtest suite\fR 
  1087. .sp 9p
  1088. .RT
  1089. .PP
  1090. A complete set of test cases, possibly combined into nested test groups, 
  1091. that is necessary to perform conformance testing or basic 
  1092. interconnection testing for an IUT or protocol within an IUT.
  1093. .RT
  1094. .sp 1P
  1095. .LP
  1096. 3.6.13
  1097.     \fBtest case\fR 
  1098. .sp 9p
  1099. .RT
  1100. .PP
  1101. A generic, abstract or executable test case.
  1102. .RT
  1103. .sp 1P
  1104. .LP
  1105. 3.6.14
  1106.     \fBtest group\fR 
  1107. .sp 9p
  1108. .RT
  1109. .PP
  1110. A named set of related test cases.
  1111. .RT
  1112. .sp 1P
  1113. .LP
  1114. 3.6.15
  1115.     \fBgeneric test suite\fR 
  1116. .sp 9p
  1117. .RT
  1118. .PP
  1119. A test suite composed of generic test cases, with the same
  1120. coverage as the complete set of test purposes for the particular protocol,
  1121. this being the set or a superset of the test purposes of any particular
  1122. abstract test suite for the same protocol.
  1123. .RT
  1124. .sp 1P
  1125. .LP
  1126. 3.6.16
  1127.     \fBabstract test suite\fR 
  1128. .sp 9p
  1129. .RT
  1130. .PP
  1131. A test suite composed of abstract test cases.
  1132. .RT
  1133. .sp 1P
  1134. .LP
  1135. 3.6.17
  1136.     \fBexecutable test suite\fR 
  1137. .sp 9p
  1138. .RT
  1139. .PP
  1140. A test suite composed of executable test cases.
  1141. .RT
  1142. .sp 1P
  1143. .LP
  1144. 3.6.18
  1145.     \fBconformance test suite\fR 
  1146. .sp 9p
  1147. .RT
  1148. .PP
  1149. A test suite for conformance testing of one or more
  1150. OSI* protocols.
  1151. .PP
  1152. \fINote\fR \ \(em\ It should cover both capability testing and behaviour
  1153. testing. It may be qualified by the adjectives: abstract, generic or
  1154. executable, as appropriate. Unless stated otherwise, an \*Qabstract test 
  1155. suite\*U is meant. 
  1156. .RT
  1157. .sp 1P
  1158. .LP
  1159. 3.6.19
  1160.     \fBbasic interconnection test suite\fR 
  1161. .sp 9p
  1162. .RT
  1163. .PP
  1164. A test suite for basic interconnection testing of one or more
  1165. OSI* protocols.
  1166. .RT
  1167. .sp 1P
  1168. .LP
  1169. 3.6.20
  1170.     \fBselected abstract test suite\fR 
  1171. .sp 9p
  1172. .RT
  1173. .PP
  1174. The subset of an abstract test suite selected using a specific
  1175. PICS.
  1176. .RT
  1177. .sp 1P
  1178. .LP
  1179. 3.6.21
  1180.     \fBselected executable test suite\fR 
  1181. .sp 9p
  1182. .RT
  1183. .PP
  1184. The subset of an executable test suite selected using a specific PICS and 
  1185. corresponding to a selected abstract test suite. 
  1186. .RT
  1187. .sp 1P
  1188. .LP
  1189. 3.6.22
  1190.     \fBparameterized abstract test case\fR 
  1191. .sp 9p
  1192. .RT
  1193. .PP
  1194. An abstract test case in which all appropriate parameters have
  1195. been supplied with values in accordance with a specific PICS and
  1196. PIXIT.
  1197. .RT
  1198. .sp 1P
  1199. .LP
  1200. 3.6.23
  1201.     \fBparameterized executable test case\fR 
  1202. .sp 9p
  1203. .RT
  1204. .PP
  1205. An executable test case in which all appropriate parameters have been supplied 
  1206. with values in accordance with a specific PICS and 
  1207. PIXIT.
  1208. .RT
  1209. .sp 1P
  1210. .LP
  1211. 3.6.24
  1212.     \fBparameterized abstract test suite\fR 
  1213. .sp 9p
  1214. .RT
  1215. .PP
  1216. A selected abstract test suite in which all test cases have been made parameterized 
  1217. abstract test cases for the appropriate PICS and 
  1218. PIXIT.
  1219. .bp
  1220. .RT
  1221. .sp 1P
  1222. .LP
  1223. 3.6.25
  1224.     \fBparameterized executable test suite\fR 
  1225. .sp 9p
  1226. .RT
  1227. .PP
  1228. A selected executable test suite in which all test cases have been made 
  1229. parameterized executable test cases for the appropriate PICS and PIXIT, 
  1230. and corresponding to a parameterized abstract test suite.
  1231. .RT
  1232. .sp 2P
  1233. .LP
  1234. 3.7
  1235.     \fITerminology of results\fR 
  1236. .sp 1P
  1237. .RT
  1238. .sp 1P
  1239. .LP
  1240. 3.7.1
  1241.     \fBrepeatability (of results)\fR 
  1242. .sp 9p
  1243. .RT
  1244. .PP
  1245. Characteristic of a test case, such that repeated executions on
  1246. the same IUT lead to the same verdict, and by extension a characteristic 
  1247. of a test suite. 
  1248. .RT
  1249. .sp 1P
  1250. .LP
  1251. 3.7.2
  1252.     \fBcomparability (of results)\fR 
  1253. .sp 9p
  1254. .RT
  1255. .PP
  1256. Characteristic of conformance assessment processes, such that
  1257. their execution on the same IUT, in different test environments, leads 
  1258. to the same overall summary. 
  1259. .RT
  1260. .sp 1P
  1261. .LP
  1262. 3.7.3
  1263.     \fBoutcome\fR 
  1264. .sp 9p
  1265. .RT
  1266. .PP
  1267. A sequence of test events together with the associated
  1268. input/output, either identified by an abstract test case specifier, or 
  1269. observed during test execution. 
  1270. .RT
  1271. .sp 1P
  1272. .LP
  1273. 3.7.4
  1274.     \fBforeseen outcome\fR 
  1275. .sp 9p
  1276. .RT
  1277. .PP
  1278. An outcome identified or categorized in the abstract test case
  1279. specification.
  1280. .RT
  1281. .sp 1P
  1282. .LP
  1283. 3.7.5
  1284.     \fBunforeseen outcome\fR 
  1285. .sp 9p
  1286. .RT
  1287. .PP
  1288. An outcome not identified or categorized in the abstract test case specification. 
  1289. .RT
  1290. .sp 1P
  1291. .LP
  1292. 3.7.6
  1293.     \fBverdict\fR 
  1294. .sp 9p
  1295. .RT
  1296. .PP
  1297. Statement of \*Qpass\*U, \*Qfail\*U or \*Qinconclusive\*U concerning
  1298. conformance of an IUT with respect to a test case that has been executed and
  1299. which is specified in the abstract test suite.
  1300. .RT
  1301. .sp 1P
  1302. .LP
  1303. 3.7.7
  1304.     \fBsystem conformance test report (SCTR)\fR 
  1305. .sp 9p
  1306. .RT
  1307. .PP
  1308. A document written at the end of the conformance assessment
  1309. process, giving the overall summary of the conformance of the system to 
  1310. the set of protocols for which conformance testing was carried out. 
  1311. .RT
  1312. .sp 1P
  1313. .LP
  1314. 3.7.8
  1315.     \fBprotocol conformance test report (PCTR)\fR 
  1316. .sp 9p
  1317. .RT
  1318. .PP
  1319. A document written at the end of the conformance assessment
  1320. process, giving the details of the testing carried out for a particular
  1321. protocol, including the identification of the abstract test cases for which
  1322. corresponding executable test cases were run and for each test case the test
  1323. purpose and verdict.
  1324. .RT
  1325. .sp 1P
  1326. .LP
  1327. 3.7.9
  1328.     \fBvalid test event\fR 
  1329. .sp 9p
  1330. .RT
  1331. .PP
  1332. A test event which is allowed by the protocol Recommendation*,
  1333. being both syntactically correct and occurring or arriving in an allowed
  1334. context in an observed outcome.
  1335. .RT
  1336. .sp 1P
  1337. .LP
  1338. 3.7.10
  1339.     \fBsyntactically invalid test event\fR 
  1340. .sp 9p
  1341. .RT
  1342. .PP
  1343. A test event which syntactically is not allowed by the protocol
  1344. Recommendation*.
  1345. .PP
  1346. \fINote\fR \ \(em\ The use of \*Qinvalid test event\*U is deprecated.
  1347. .RT
  1348. .sp 1P
  1349. .LP
  1350. 3.7.11
  1351.     \fBinopportune test event\fR 
  1352. .sp 9p
  1353. .RT
  1354. .PP
  1355. A test event which, although syntactically correct, occurs or
  1356. arrives at a point in an observed outcome when not allowed to do so by the
  1357. protocol Recommendation*.
  1358. .bp
  1359. .RT
  1360. .sp 1P
  1361. .LP
  1362. 3.7.12
  1363.     \fB\*Qpass\*U verdict\fR 
  1364. .sp 9p
  1365. .RT
  1366. .PP
  1367. A verdict given when the observed outcome satisfies the test
  1368. purpose and is valid with respect to the relevant Recommendation(s)*
  1369. and with respect to the PICS.
  1370. .RT
  1371. .sp 1P
  1372. .LP
  1373. 3.7.13
  1374.     \fB\*Qfail\*U verdict\fR 
  1375. .sp 9p
  1376. .RT
  1377. .PP
  1378. A verdict given when the observed outcome is syntactically invalid or inopportune 
  1379. with respect to the relevant Recommendation(s)* or the 
  1380. PICS.
  1381. .RT
  1382. .sp 1P
  1383. .LP
  1384. 3.7.14
  1385.     \fB\*Qinconclusive\*U verdict\fR 
  1386. .sp 9p
  1387. .RT
  1388. .PP
  1389. A verdict given when the observed outcome is valid with respect to the 
  1390. relevant Recommendation(s)* but prevents the test purpose from being 
  1391. accomplished.
  1392. .RT
  1393. .sp 1P
  1394. .LP
  1395. 3.7.15
  1396.     \fBconformance log\fR 
  1397. .sp 9p
  1398. .RT
  1399. .PP
  1400. A record of sufficient information necessary to verify verdict
  1401. assignments as a result of conformance testing.
  1402. .RT
  1403. .sp 2P
  1404. .LP
  1405. 3.8
  1406.     \fITerminology of test methods\fR 
  1407. .sp 1P
  1408. .RT
  1409. .sp 1P
  1410. .LP
  1411. 3.8.1
  1412.     \fBpoint of control and observation (PCO)\fR 
  1413. .sp 9p
  1414. .RT
  1415. .PP
  1416. A point at which control and observation is specified in a test
  1417. case.
  1418. .RT
  1419. .sp 1P
  1420. .LP
  1421. 3.8.2
  1422.     \fBlower tester\fR 
  1423. .sp 9p
  1424. .RT
  1425. .PP
  1426. The abstraction of the means of providing, during test execution, control 
  1427. and observation at the appropriate PCO either below the IUT or remote from 
  1428. the IUT, as defined by the chosen abstract test method. 
  1429. .RT
  1430. .sp 1P
  1431. .LP
  1432. 3.8.3
  1433.     \fBupper tester\fR 
  1434. .sp 9p
  1435. .RT
  1436. .PP
  1437. The abstraction of the means of providing, during test execution, control 
  1438. and observation of the upper service boundary of the IUT, plus the 
  1439. control and observation of any relevant abstract local primitive.
  1440. .RT
  1441. .sp 1P
  1442. .LP
  1443. 3.8.4
  1444.     \fBabstract (N)\(hyservice\(hyprimitive ((N)\(hyASP)\fR 
  1445. .sp 9p
  1446. .RT
  1447. .PP
  1448. An implementation independent description of an interaction
  1449. between a service\(hyuser and a service\(hyprovider at an (N)\(hyservice 
  1450. boundary, as 
  1451. defined in an OSI* service definition Recommendation*.
  1452. .RT
  1453. .sp 1P
  1454. .LP
  1455. 3.8.5
  1456.     \fBabstract local primitive (ALP)\fR 
  1457. .sp 9p
  1458. .RT
  1459. .PP
  1460. An abbreviation for a description of control and/or observation to be performed 
  1461. by the upper tester, which cannot be described in terms of ASPs 
  1462. but which relates to events or states defined within the protocol
  1463. Recommendation(s)* relevant to the IUT.
  1464. .PP
  1465. \fINote\fR \ \(em\ The PIXIT will indicate whether or not a particular 
  1466. ALP can be realized within the SUT. The ability of the SUT to support particular 
  1467. ALPs as specified in the PIXIT will be used as a criterion in the test 
  1468. selection 
  1469. process.
  1470. .RT
  1471. .sp 1P
  1472. .LP
  1473. 3.8.6
  1474.     \fBtest coordination procedures\fR 
  1475. .sp 9p
  1476. .RT
  1477. .PP
  1478. The rules for cooperation between the lower and upper testers
  1479. during testing.
  1480. .RT
  1481. .sp 1P
  1482. .LP
  1483. 3.8.7
  1484.     \fBtest management protocol\fR 
  1485. .sp 9p
  1486. .RT
  1487. .PP
  1488. A protocol which is used as a realization of the test coordination procedures 
  1489. for a particular test suite. 
  1490. .RT
  1491. .sp 1P
  1492. .LP
  1493. 3.8.8
  1494.     \fBlocal test methods\fR 
  1495. .sp 9p
  1496. .RT
  1497. .PP
  1498. Abstract test methods in which the PCOs are directly at the layer boundaries 
  1499. of the IUT. 
  1500. .bp
  1501. .RT
  1502. .sp 1P
  1503. .LP
  1504. 3.8.9
  1505.     \fBexternal test methods\fR 
  1506. .sp 9p
  1507. .RT
  1508. .PP
  1509. Abstract test methods in which the lower tester is separate from the SUT 
  1510. and communicates with it via an appropriate lower layer 
  1511. service\(hyprovider.
  1512. .PP
  1513. \fINote\fR \ \(em\ The service\(hyprovider is immediately beneath the (lowest
  1514. layer) protocol which is the focus of the testing, and may involve multiple 
  1515. OSI layers. 
  1516. .RT
  1517. .sp 1P
  1518. .LP
  1519. 3.8.10
  1520.     \fBdistributed test method\fR 
  1521. .sp 9p
  1522. .RT
  1523. .PP
  1524. An external test method in which there is a PCO at the layer
  1525. boundary at the top of the IUT.
  1526. .RT
  1527. .sp 1P
  1528. .LP
  1529. 3.8.11
  1530.     \fBcoordinated test method\fR 
  1531. .sp 9p
  1532. .RT
  1533. .PP
  1534. An external test method for which a standardized test management protocol 
  1535. is defined as the realization of the test coordination procedures, 
  1536. enabling the control and observation to be specified solely in terms of the
  1537. lower tester activity, including the control and observation of test management 
  1538. PDUs. 
  1539. .RT
  1540. .sp 1P
  1541. .LP
  1542. 3.8.12
  1543.     \fBremote test method\fR 
  1544. .sp 9p
  1545. .RT
  1546. .PP
  1547. An external method in which there is neither a PCO above the IUT nor a 
  1548. standardized test management protocol; some requirements for test 
  1549. coordination procedures may be implied or informally expressed in the abstract 
  1550. test suite but no assumption is made regarding their feasibility or 
  1551. realization.
  1552. .RT
  1553. .sp 1P
  1554. .LP
  1555. 3.8.13
  1556.     \fBreal tester\fR 
  1557. .sp 9p
  1558. .RT
  1559. .PP
  1560. The realization of the lower tester, plus either the definition
  1561. or the realization of the upper tester, plus the definition of the test
  1562. coordination procedures, as appropriate to a particular test
  1563. method.
  1564. .RT
  1565. .sp 1P
  1566. .LP
  1567. 3.8.14
  1568.     \fBtest realizer\fR 
  1569. .sp 9p
  1570. .RT
  1571. .PP
  1572. An organization which takes responsibility for providing, in a
  1573. form independent of client and IUT, the means of testing IUTs in conformance
  1574. with the abstract test suite.
  1575. .RT
  1576. .sp 2P
  1577. .LP
  1578. \fB4\fR     \fBAbbreviations\fR 
  1579. .sp 1P
  1580. .RT
  1581. .PP
  1582. For the purposes of this Recommendation the following
  1583. abbreviations apply:
  1584. .RT
  1585. .LP
  1586.     Administration*
  1587.     Administration or recognized private
  1588. operating agency
  1589. .LP
  1590.     ALP 
  1591.     abstract local primitive
  1592. .LP
  1593.     ASP 
  1594.     abstract service primitive
  1595. .LP
  1596.     DTE 
  1597.     data terminal equipment
  1598. .LP
  1599.     IUT 
  1600.     implementation under test
  1601. .LP
  1602.     OSI 
  1603.     open systems interconnection
  1604. .LP
  1605.     OSI* 
  1606.     OSI or related CCITT X\(hyseries or T\(hyseries Recommendations
  1607. .LP
  1608.     PCO
  1609.     point of control and observation
  1610. .LP
  1611.     PCTR 
  1612.     protocol conformance test report
  1613. .LP
  1614.     PDU
  1615.     protocol data unit
  1616. .LP
  1617.     PICS 
  1618.     protocol implementation conformance statement
  1619. .LP
  1620.     PIXIT
  1621.     protocol implementation extra information for testing
  1622. .LP
  1623.     BBSAP
  1624.     service access point
  1625. .LP
  1626.     SCTR
  1627.     system conformance test report
  1628. .LP
  1629.     Recommendation*
  1630.     Standard or Recommendation
  1631. .LP
  1632.     SUT
  1633.     system under test
  1634. .LP
  1635.     TM\(hyPDU
  1636.     test management PDU
  1637. .LP
  1638. .rs
  1639. .sp 02P
  1640. .ad r
  1641. BLANC
  1642. .ad b
  1643. .RT
  1644. .LP
  1645. .bp
  1646. .sp 1P
  1647. .ce 1000
  1648. SECTION\ 2\ \(em\ \fIOverview\fR 
  1649. .sp 1P
  1650. .RT
  1651. .ce 0
  1652. .sp 1P
  1653. .sp 2P
  1654. .LP
  1655. \fB5\fR     \fBThe meaning of conformance in OSI\fR 
  1656. .sp 1P
  1657. .RT
  1658. .sp 1P
  1659. .LP
  1660. 5.1
  1661.     \fIIntroduction\fR 
  1662. .sp 9p
  1663. .RT
  1664. .PP
  1665. In the context of OSI*, a real system is said to exhibit
  1666. conformance if it complies with the requirements of applicable OSI*
  1667. Recommendations* in its communication with other real systems.
  1668. .PP
  1669. Applicable OSI* Recommendations* include protocol Recommendations*,
  1670. and transfer syntax Recommendations* inasmuch as they are implemented
  1671. in conjunction with protocols.
  1672. .PP
  1673. OSI* Recommendations* form a set of interrelated
  1674. Recommendations* which together define behaviour of open systems in
  1675. their communication. Conformance of a real system will, therefore, be expressed 
  1676. at two levels, conformance to each individual Recommendation*, and 
  1677. conformance to the set.
  1678. .PP
  1679. \fINote\fR \ \(em\ If the implementation is based on a predefined set of
  1680. Recommendations*, often referred to as a functional standard or profile, the
  1681. concept of conformance can be extended to specific requirements expressed in
  1682. the functional standard or profile, as long as they do not conflict with the
  1683. requirements of the base Recommendations*.
  1684. .RT
  1685. .sp 2P
  1686. .LP
  1687. 5.2
  1688.     \fIConformance requirements\fR 
  1689. .sp 1P
  1690. .RT
  1691. .PP
  1692. 5.2.1
  1693. The conformance requirements in a Recommendation* can be:
  1694. .sp 9p
  1695. .RT
  1696. .LP
  1697.     a)
  1698.     mandatory requirements: these are to be observed in all
  1699. cases;
  1700. .LP
  1701.     b)
  1702.     conditional requirements: these are to be observed if the
  1703. conditions set out in the Recommendation* apply;
  1704. .LP
  1705.     c)
  1706.      options: these can be selected to suit the implementation, provided that 
  1707. any requirements applicable to the option are observed. More 
  1708. information on options is provided in Annex\ A.
  1709. .PP
  1710. For example, CCITT essential facilities are mandatory
  1711. requirements; additional facilities can be either conditional or optional
  1712. requirements.
  1713. .PP
  1714. \fINote\fR \ \(em\ The CCITT terms \*Qessential facilities\*U and \*Qadditional
  1715. facilities\*U need to be considered in the context of the scope of the CCITT
  1716. Recommendation concerned; in many cases, essential facilities are mandatory 
  1717. for networks but not for DTEs. 
  1718. .RT
  1719. .PP
  1720. 5.2.2
  1721. Furthermore, conformance requirements in a Recommendation* can be   stated
  1722. .sp 9p
  1723. .RT
  1724. .LP
  1725.     a)
  1726.     positively: they state what shall be done;
  1727. .LP
  1728.     b)
  1729.     negatively (prohibitions): they state what shall not be
  1730. done.
  1731. .PP
  1732. 5.2.3
  1733. Finally, conformance requirements fall into two
  1734. groups:
  1735. .sp 9p
  1736. .RT
  1737. .LP
  1738.     a)
  1739.     static conformance requirements;
  1740. .LP
  1741.     b)
  1742.     dynamic conformance requirements;
  1743. .LP
  1744. these are discussed in \(sc\(sc 5.3. and 5.5, respectively.
  1745. .sp 1P
  1746. .LP
  1747. 5.3
  1748.     \fIStatic conformance requirements\fR 
  1749. .sp 9p
  1750. .RT
  1751. .PP
  1752. Static conformance requirements are those that define the allowed minimum 
  1753. capabilities of an implementation, in order to facilitate interworking. 
  1754. These requirements may be at a broad level, such as the grouping of functional 
  1755. units and options into protocol classes, or at a detailed level, such as 
  1756. a 
  1757. range of values that have to be supported for specific parameters of
  1758. timers.
  1759. .bp
  1760. .PP
  1761. Static conformance requirements and options in OSI* Recommendations* can 
  1762. be of two varieties: 
  1763. .RT
  1764. .LP
  1765.     a)
  1766.     those which determine the capabilities to be included in
  1767. the implementation of the particular protocol;
  1768. .LP
  1769.     b)
  1770.      those which determine multi\(hylayer dependencies, e.g., those which 
  1771. place constraints on the capabilities of the underlying layers of the 
  1772. system in which the protocol implementation resides. These are likely to be
  1773. found in upper layer Recommendations*.
  1774. .PP
  1775. All capabilities not explicitly stated as static conformance
  1776. requirements are to be regarded as optional.
  1777. .sp 1P
  1778. .LP
  1779. 5.4
  1780.     \fIProtocol implementation conformance statement (PICS)\fR 
  1781. .sp 9p
  1782. .RT
  1783. .PP
  1784. To evaluate the conformance of a particular implementation, it is necessary 
  1785. to have a statement of the capabilities and options which have been implemented, 
  1786. and any features which have been omitted, so that the 
  1787. implementation can be tested for conformance against relevant requirements, 
  1788. and against those requirements only. Such a statement is called a Protocol 
  1789. Implementation Conformance Statement (PICS).
  1790. .PP
  1791. In a PICS there should be a distinction between the following
  1792. categories of information which it may contain:
  1793. .RT
  1794. .LP
  1795.     a)
  1796.     information related to the mandatory, optional and
  1797. conditional static conformance requirements of the protocol
  1798. itself;
  1799. .LP
  1800.     b)
  1801.     information related to the mandatory, optional and
  1802. conditional static conformance requirements for multi\(hylayer
  1803. dependencies.
  1804. .PP
  1805. If a set of interrelated OSI* protocol Recommendations* has been implemented 
  1806. in a system, a PICS is needed for each protocol. A System 
  1807. Conformance Statement will also be necessary, summarizing all protocols 
  1808. in the system for each of which a distinct PICS is provided. 
  1809. .sp 1P
  1810. .LP
  1811. 5.5
  1812.     \fIDynamic conformance requirements\fR 
  1813. .sp 9p
  1814. .RT
  1815. .PP
  1816. Dynamic conformance requirements are all those requirements (and
  1817. options) which determine what observable behaviour is permitted by the 
  1818. relevant OSI* Recommendation(s)* in instances of communication. They form 
  1819. the bulk 
  1820. of each OSI* protocol Recommendation*. They define the set of
  1821. allowable behaviours of an implementation or real system. This set defines 
  1822. the maximum capability that a conforming implementation or real system 
  1823. can have 
  1824. within the terms of the OSI* protocol Recommendation*.
  1825. .PP
  1826. A system exhibits dynamic conformance in an instance of communication if 
  1827. its behaviour is a member of the set of all behaviours permitted by the 
  1828. relevant OSI* protocol Recommendation(s)* in a way which is consistent 
  1829. with the PICS. 
  1830. .RT
  1831. .sp 1P
  1832. .LP
  1833. 5.6
  1834.     \fIA conforming system\fR 
  1835. .sp 9p
  1836. .RT
  1837. .PP
  1838. A conforming system or implementation is one which is shown to
  1839. satisfy both static and dynamic conformance requirements, consistent with 
  1840. the capabilities stated in the PICS, for each protocol declared in the 
  1841. System 
  1842. Conformance Statement.
  1843. .RT
  1844. .sp 2P
  1845. .LP
  1846. 5.7
  1847.     \fIInterworking and conformance\fR 
  1848. .sp 1P
  1849. .RT
  1850. .PP
  1851. 5.7.1
  1852. The primary purpose of conformance testing is to increase the
  1853. probability that different implementations are able to interwork.
  1854. .sp 9p
  1855. .RT
  1856. .PP
  1857. Successful interworking of two or more real open systems is more likely 
  1858. to be achieved if they all conform to the same subset of an OSI* 
  1859. Recommendation*, or to the same selection of OSI* Recommendations*, than if
  1860. they do not.
  1861. .PP
  1862. In order to prepare two or more systems to interwork successfully, it is 
  1863. recommended that a comparison be made of the System Conformance Statements 
  1864. and PICSs of these systems. 
  1865. .PP
  1866. If there is more than one version of a relevant OSI* Recommendation* indicated 
  1867. in the PICSs, the differences between the versions need to be 
  1868. identified and their implications for consideration, including their use in
  1869. combination with other Recommendations*.
  1870. .RT
  1871. .PP
  1872. 5.7.2 
  1873. While conformance is a necessary condition, it is not on its
  1874. own a sufficient condition to guarantee interworking capability. Even if two
  1875. implementations conform to the same OSI* protocol Recommendation*, they may
  1876. fail to interwork because of factors outside the scope of that
  1877. Recommendation.
  1878. .bp
  1879. .sp 9p
  1880. .RT
  1881. .PP
  1882. Trial interworking is recommended in order to detect these
  1883. factors. Further information to assist interworking between two systems 
  1884. can be obtained by extending the PICS comparison to other relevant information, 
  1885. including test reports and PIXIT (see \(sc\ 6.2). The comparison can focus
  1886. on:
  1887. .LP
  1888.     a)
  1889.     additional mechanisms claimed to work around known
  1890. ambiguities or deficiencies not yet corrected in the
  1891. Recommendations* or in peer real systems, e.g.\ solution
  1892. of multi\(hylayer problems;
  1893. .LP
  1894.     b)
  1895.      selection of free options which are not taken into account in the static 
  1896. conformance requirements of the 
  1897. Recommendations*;
  1898. .LP
  1899.     c)
  1900.     the existence of timers not specified in the
  1901. Recommendation* and their associated values.
  1902. .PP
  1903. \fINote\fR \ \(em\ The comparison can be made between two individual
  1904. systems, between two or more types of product, or, for the PICS comparison
  1905. only, between two or more specifications for procurement, permissions to
  1906. connect,\ etc.
  1907. .LP
  1908. \fB6\fR     \fBConformance and testing\fR 
  1909. .sp 1P
  1910. .RT
  1911. .sp 2P
  1912. .LP
  1913. 6.1
  1914.     \fIObjectives of conformance testing\fR 
  1915. .sp 1P
  1916. .RT
  1917. .sp 1P
  1918. .LP
  1919. 6.1.1
  1920.     \fIIntroduction\fR 
  1921. .sp 9p
  1922. .RT
  1923. .PP
  1924. Conformance testing as discussed in this Recommendation is focused on testing 
  1925. for conformance to OSI* protocol Recommendations*. However, it also applies 
  1926. to testing for conformance to OSI* transfer syntax Recommendations*, to 
  1927. the extent that this can be carried out by testing the transfer syntax 
  1928. in 
  1929. combination with an OSI* protocol.
  1930. .PP
  1931. In principle, the objective of conformance testing is to establish
  1932. whether the implementation being tested conforms to the specification in the
  1933. relevant Recommendation*. Practical limitations make it impossible to
  1934. be exhaustive, and economic considerations may restrict testing still
  1935. further.
  1936. .PP
  1937. Therefore, this Recommendation distinguishes four types of testing,
  1938. according to the extent to which they provide an indication of
  1939. conformance:
  1940. .RT
  1941. .LP
  1942.     a)
  1943.     basic interconnection tests, which provide \fIprima facie\fR \|
  1944. evidence that an IUT conforms;
  1945. .LP
  1946.     b)
  1947.     capability tests, which check that the observable
  1948. capabilities of the IUT are in accordance with the static conformance
  1949. requirements and the capabilities claimed in the PICS;
  1950. .LP
  1951.     c)
  1952.     behaviour tests, which endeavour to provide testing which
  1953. is as comprehensive as possible over the full range of dynamic conformance
  1954. requirements specified by the Recommendation*, within the capabilities
  1955. of the IUT;
  1956. .LP
  1957.     d)
  1958.     conformance resolution tests, which probe in depth the
  1959. conformance of an IUT to particular requirements, to provide a definite 
  1960. yesB/Fno answer and diagnostic information in relation to specific conformance 
  1961. issues; such tests are not standardized. 
  1962. .sp 2P
  1963. .LP
  1964. 6.1.2
  1965.     \fIBasic interconnection tests\fR 
  1966. .sp 1P
  1967. .RT
  1968. .PP
  1969. 6.1.2.1
  1970. Basic interconnection tests provide limited testing of an IUT in relation 
  1971. to the main features in a Recommendation*, to establish that there is sufficient 
  1972. conformance for interconnection to be possible, without trying to 
  1973. perform thorough testing.
  1974. .sp 9p
  1975. .RT
  1976. .PP
  1977. 6.1.2.2
  1978. Basic interconnection tests are appropriate:
  1979. .sp 9p
  1980. .RT
  1981. .LP
  1982.     a)
  1983.     for detecting severe cases of non\(hyconformance;
  1984. .LP
  1985.     b)
  1986.     as a preliminary filter before undertaking more costly
  1987. tests;
  1988. .LP
  1989.     c)
  1990.      to give a \fIprima facie\fR \| indication that an implementation which 
  1991. has passed full conformance tests in one environment still conforms in 
  1992. a new environment (e.g.\ before testing an (N)\(hyimplementation, to check 
  1993. that a 
  1994. tested (N\ \(em\ 1)\(hyimplementation has not undergone any severe change 
  1995. due to being linked to the (N)\(hyimplementation); 
  1996. .LP
  1997.     d)
  1998.     for use by users of implementations, to determine whether
  1999. the implementations appear to be usable for communication with other conforming 
  2000. implementations, e.g.\ as a preliminary to data interchange. 
  2001. .bp
  2002. .PP
  2003. 6.1.2.3 
  2004. Basic interconnection tests are inappropriate:
  2005. .sp 9p
  2006. .RT
  2007. .LP
  2008.     a)
  2009.     as a basis for claims of conformance by the supplier of an   implementation;
  2010. .LP
  2011.     b)
  2012.     as a means of arbitration to determine causes for
  2013. communications failure.
  2014. .PP
  2015. 6.1.2.4 
  2016. Basic interconnection tests should be standardized as either a very small 
  2017. test suite or a subset of a conformance test suite (including 
  2018. capability and behaviour tests). They can be used on their own or together 
  2019. with a conformance test suite. The existence and execution of basic interconnection 
  2020. tests are optional. 
  2021. .sp 9p
  2022. .RT
  2023. .sp 2P
  2024. .LP
  2025. 6.1.3
  2026.     \fICapability tests\fR 
  2027. .sp 1P
  2028. .RT
  2029. .PP
  2030. 6.1.3.1
  2031. Capability tests provide limited testing of each of the static
  2032. conformance requirements in a Recommendation*, to ascertain what capabilities 
  2033. of the IUT can be observed and to check that those observable capabilities 
  2034. are valid with respect to the static conformance requirements and the PICS. 
  2035. .sp 9p
  2036. .RT
  2037. .PP
  2038. 6.1.3.2
  2039. Capability tests are appropriate:
  2040. .sp 9p
  2041. .RT
  2042. .LP
  2043.     a)
  2044.     to check as far as possible the consistency of the PICS
  2045. with the IUT;
  2046. .LP
  2047.     b)
  2048.     as a preliminary filter before undertaking more in\(hydepth
  2049. and costly testing;
  2050. .LP
  2051.     c)
  2052.     to check that the capabilities of the IUT are consistent
  2053. with the static conformance requirements;
  2054. .LP
  2055.     d)
  2056.      to enable efficient selection of behaviour tests to be made for a particular 
  2057. IUT; 
  2058. .LP
  2059.     e)
  2060.     when taken together with behaviour tests, as a basis for
  2061. claims of conformance.
  2062. .PP
  2063. 6.1.3.3 
  2064. Capability tests are inappropriate:
  2065. .sp 9p
  2066. .RT
  2067. .LP
  2068.     a)
  2069.     on their own, as a basis for claims of conformance by the
  2070. supplier of an implementation;
  2071. .LP
  2072.     b)
  2073.     for testing in detail the behaviour associated with each
  2074. capability which has been implemented or not implemented;
  2075. .LP
  2076.     c)
  2077.      for resolution of problems experienced during live usage or where other 
  2078. tests indicate possible non\(hyconformance even though the capability tests 
  2079. have been satisfied. 
  2080. .PP
  2081. 6.1.3.4 
  2082. Capability tests are standardized within a conformance test
  2083. suite. They can either be separated into their own test group(s) or merged 
  2084. with the behaviour tests. 
  2085. .sp 9p
  2086. .RT
  2087. .sp 2P
  2088. .LP
  2089. 6.1.4
  2090.     \fIBehaviour tests\fR 
  2091. .sp 1P
  2092. .RT
  2093. .PP
  2094. 6.1.4.1
  2095. Behaviour tests test an implementation as thoroughly as is
  2096. practical, over the full range of dynamic conformance requirements
  2097. specified in a Recommendation*. Since the number of possible combinations of
  2098. events and timing of events is infinite, such testing cannot be exhaustive.
  2099. There is a further limitation, namely that these tests are designed
  2100. to be run collectively in a single test environment, so that any faults 
  2101. which are difficult or impossible to detect in that environment are likely 
  2102. to be 
  2103. missed. Therefore, it is possible that a non\(hyconforming implementation 
  2104. passes the conformance test suite; one aim of the test suite design is 
  2105. to minimize the number of times that this occurs. 
  2106. .sp 9p
  2107. .RT
  2108. .PP
  2109. 6.1.4.2 
  2110. Behaviour tests are appropriate, when taken together with
  2111. capability tests, as a basis for the conformance assessment process.
  2112. .sp 9p
  2113. .RT
  2114. .PP
  2115. 6.1.4.3 
  2116. Behaviour tests are inappropriate for resolution of problems
  2117. experienced during live usage or where other tests indicate possible
  2118. non\(hyconformance even though the behaviour tests have been satisfied.
  2119. .sp 9p
  2120. .RT
  2121. .PP
  2122. 6.1.4.4 
  2123. Behaviour tests are standardized as the bulk of a conformance
  2124. test suite.
  2125. .sp 9p
  2126. .RT
  2127. .PP
  2128. \fINote\fR \ \(em\ Behaviour tests include tests for valid behaviour by 
  2129. the IUT in response to valid, inopportune and syntactically invalid protocol 
  2130. behaviour by the real tester. This includes testing the rejection by the 
  2131. IUT of attempts to use features (capabilities) which are stated in the 
  2132. PICS as being not implemented. Thus, capability tests do not need to include 
  2133. tests for 
  2134. capabilities omitted from the PICS.
  2135. .bp
  2136. .sp 2P
  2137. .LP
  2138. 6.1.5
  2139.     \fIConformance resolution tests\fR 
  2140. .sp 1P
  2141. .RT
  2142. .PP
  2143. 6.1.5.1 
  2144. Conformance resolution tests provide diagnostic answers, as near to definitive 
  2145. as possible, to the resolution of whether an implementation 
  2146. satisfies particular requirements. Because of the problems of exhaustiveness
  2147. noted in \(sc\ 6.1.4.1, the definite answers are gained at the expense 
  2148. of confining tests to a narrow field. 
  2149. .sp 9p
  2150. .RT
  2151. .PP
  2152. 6.1.5.2 
  2153. The test architecture and test method will normally be
  2154. chosen specifically for the requirements to be tested, and need not be ones
  2155. that are generally useful for other requirements. They may even be ones that
  2156. are regarded as being unacceptable for (standardized) abstract conformance 
  2157. test suites, e.g.\ involving implementation\(hyspecific methods using, 
  2158. say, the 
  2159. diagnostic and debugging facilities of the specific operating system.
  2160. .sp 9p
  2161. .RT
  2162. .PP
  2163. 6.1.5.3 
  2164. The distinction between behaviour tests and conformance
  2165. resolution tests may be illustrated by the case of an event such as a Reset.
  2166. The behaviour tests may include only a representative selection of conditions 
  2167. under which a Reset might occur, and may fail to detect incorrect behaviour 
  2168. in other circumstances. The conformance resolution tests would be confined 
  2169. to 
  2170. conditions under which incorrect behaviour was already suspected to occur, 
  2171. and would confirm whether or not the suspicions were correct. 
  2172. .sp 9p
  2173. .RT
  2174. .PP
  2175. 6.1.5.4 
  2176. Conformance resolution tests are appropriate:
  2177. .sp 9p
  2178. .RT
  2179. .LP
  2180.     a)
  2181.     for providing a yesB/Fno answer in a strictly confined and
  2182. previously identified situation (e.g.\ during implementation
  2183. development, to check whether a particular feature has been
  2184. correctly implemented, or during operational use, to investigate the cause 
  2185. of problems); 
  2186. .LP
  2187.     b)
  2188.     as a means for identifying and offering resolutions for
  2189. deficiencies in a current conformance test suite.
  2190. .PP
  2191. 6.1.5.5 
  2192. Conformance resolution tests are inappropriate as a
  2193. basis for judging whether or not an implementation conforms
  2194. overall.
  2195. .sp 9p
  2196. .RT
  2197. .PP
  2198. 6.1.5.6 
  2199. Conformance resolution tests are not standardized.
  2200. .sp 9p
  2201. .RT
  2202. .PP
  2203. \fINote\fR on \(sc 6.1\ \(em\ As a by\(hyproduct of conformance testing, 
  2204. errors and deficiencies in protocol Recommendations* may be identified. 
  2205. .sp 1P
  2206. .LP
  2207. 6.2
  2208.     \fIProtocol implementation extra information for testing\fR 
  2209. \fI(PIXIT)\fR 
  2210. .sp 9p
  2211. .RT
  2212. .PP
  2213. In order to test a protocol implementation, the test laboratory
  2214. will require information relating to the IUT and its testing environment in
  2215. addition to that provided by the PICS. This \*QProtocol Implementation eXtra
  2216. Information for Testing\*U (PIXIT) will be provided by the client submitting 
  2217. the implementation for testing, as a result of consultation with the test 
  2218. laboratory.
  2219. .PP
  2220. The PIXIT may contain the following information:
  2221. .RT
  2222. .LP
  2223.     a)
  2224.     information needed by the test laboratory in order to be
  2225. able to run the appropriate test suite on the specific system
  2226. (e.g.,\ information related to the test method to be used to run the test
  2227. cases, addressing information);
  2228. .LP
  2229.     b)
  2230.     information already mentioned in the PICS and which needs
  2231. to be made precise (e.g.\ a timer value range which is declared as a parameter 
  2232. in the PICS should be specified in the PIXIT); 
  2233. .LP
  2234.     c)
  2235.      information to help determine which capabilities stated in the PICS as 
  2236. being supported are testable and which are untestable; 
  2237. .LP
  2238.     d)
  2239.     other administrative matters (e.g. the IUT identifier,
  2240. reference to the related PICS).
  2241. .PP
  2242. The PIXIT should not conflict with the appropriate PICS.
  2243. .PP
  2244. The abstract test suite specifier, test realizer and test
  2245. laboratory will all contribute to the development of the PIXIT
  2246. proforma.
  2247. .bp
  2248. .RT
  2249. .sp 2P
  2250. .LP
  2251. 6.3
  2252.     \fIConformance assessment process outline\fR 
  2253. .sp 1P
  2254. .RT
  2255. .PP
  2256. 6.3.1 
  2257. The main feature of the conformance assessment process is a
  2258. configuration of equipment allowing exchanges of information between
  2259. the IUT and a real tester. These are controlled and observed by the real
  2260. tester.
  2261. .sp 9p
  2262. .RT
  2263. .PP
  2264. 6.3.2 
  2265. In conceptual outline, conformance testing should include several steps, 
  2266. involving both static conformance reviews and live testing phases, 
  2267. culminating in the production of a test report which is as thorough as is
  2268. practical.
  2269. .sp 9p
  2270. .RT
  2271. .PP
  2272. 6.3.3 
  2273. These steps are:
  2274. .sp 9p
  2275. .RT
  2276. .LP
  2277.     a)
  2278.     analysis of the PICS;
  2279. .LP
  2280.     b)
  2281.     test selection and parameterization;
  2282. .LP
  2283.     c)
  2284.     basic interconnection testing (optional);
  2285. .LP
  2286.     d)
  2287.     capability testing;
  2288. .LP
  2289.     e)
  2290.     behaviour testing;
  2291. .LP
  2292.     f
  2293. )
  2294.     review and analysis of test results;
  2295. .LP
  2296.     g)
  2297.     synthesis, conclusions and conformance test report
  2298. production.
  2299. .PP
  2300. These are illustrated in Figure 1/X.290 Part\ 1.
  2301. .PP
  2302. Prior to the execution of any of the tests, the IUT's PICS and PIXIT are 
  2303. input to the test case selection and parameterization process. 
  2304. .RT
  2305. .LP
  2306. .rs
  2307. .sp 33P
  2308. .ad r
  2309. \fBFigure 1/X.290, partie 1, (N), p.\fR 
  2310. .sp 1P
  2311. .RT
  2312. .ad b
  2313. .RT
  2314. .LP
  2315. .bp
  2316. .LP
  2317. 6.4
  2318.     \fIAnalysis of results\fR 
  2319. .sp 1P
  2320. .RT
  2321. .sp 2P
  2322. .LP
  2323. 6.4.1
  2324.     \fIGeneral\fR 
  2325. .sp 1P
  2326. .RT
  2327. .sp 1P
  2328. .LP
  2329. 6.4.1.1
  2330.     \fIOutcomes and verdicts\fR 
  2331. .sp 9p
  2332. .RT
  2333. .PP
  2334. The observed outcome (of the test execution) is the series of
  2335. events which occurred during execution of a test case; it includes all 
  2336. input to and output from the IUT at the points of control and observation. 
  2337. .PP
  2338. The foreseen outcomes are identified and defined by the abstract
  2339. test case specification taken in conjunction with the protocol
  2340. Recommendation*. For each test case, there may be one or more foreseen
  2341. outcomes. Foreseen outcomes are defined primarily in abstract terms.
  2342. .PP
  2343. A verdict is a statement of pass, fail or inconclusive to be
  2344. associated with every foreseen outcome in the abstract test suite
  2345. specification.
  2346. .PP
  2347. The analysis of results is performed by comparing the observed
  2348. outcomes with foreseen outcomes.
  2349. .PP
  2350. The verdict assigned to an observed outcome is that associated with
  2351. the matching foreseen outcome. If the observed outcome is unforeseen then 
  2352. the abstract test suite specification will state what default verdict shall 
  2353. be 
  2354. assigned.
  2355. .PP
  2356. The means by which the comparison of the observed outcomes with
  2357. the foreseen outcomes is made is outside the scope of this Recommendation.
  2358. .PP
  2359. \fINote\fR \ \(em\ Amongst the possibilities are:
  2360. .RT
  2361. .LP
  2362.     a)
  2363.     manual or automated comparison (or a mixture);
  2364. .LP
  2365.     b)
  2366.     comparison at or after execution time;
  2367. .LP
  2368.     c)
  2369.     translating the observed outcomes into abstract terms for
  2370. comparison with the foreseen outcomes or translating the
  2371. foreseen outcomes into the terms used to record the observed
  2372. outcomes.
  2373. .PP
  2374. The verdict will be pass, fail or inconclusive:
  2375. .LP
  2376.     a)
  2377.     pass means that the observed outcome satisfies the test
  2378. purpose and is valid with respect to the relevant Recommendation(s)* and 
  2379. with respect to the PICS; 
  2380. .LP
  2381.     b)
  2382.     fail means that the observed outcome is syntactically
  2383. invalid or inopportune with respect to the relevant Recommendation(s)* 
  2384. or the PICS; 
  2385. .LP
  2386.     c)
  2387.      inconclusive means that the observed outcome is valid with respect to 
  2388. the relevant Recommendation(s)* but prevents the test purpose from being 
  2389. accomplished. 
  2390. .PP
  2391. The verdict assigned to a particular outcome will depend on the
  2392. test purpose and the validity of the observed protocol behaviour.
  2393. .PP
  2394. The verdicts made in respect of individual test cases will be
  2395. synthesized into an overall summary for the IUT based on the test cases
  2396. executed.
  2397. .RT
  2398. .sp 1P
  2399. .LP
  2400. 6.4.1.2
  2401.     \fIConformance test reports\fR 
  2402. .sp 9p
  2403. .RT
  2404. .PP
  2405. The results of conformance testing will be documented in a set of conformance 
  2406. test reports. These reports will be of two types: a System 
  2407. Conformance Test Report (SCTR), and a Protocol Conformance Test Report
  2408. (PCTR).
  2409. .PP
  2410. The SCTR, which will always be provided, gives an overall summary
  2411. of the conformance status of the SUT, with respect to its single or multi\(hylayer 
  2412. IUT. A standard proforma for the SCTR is for further study. 
  2413. .PP
  2414. The PCTR, one of which will be issued for each protocol tested in the SUT, 
  2415. documents all of the results of the test cases giving references to the 
  2416. conformance logs which contain the observed outcomes.  The PCTR also gives
  2417. reference to all necessary documents relating to the conduct of the conformance 
  2418. assessment process for that protocol. 
  2419. .PP
  2420. A standard proforma for the PCTR is for further study. The ordered
  2421. list of test cases to be used in the PCTR will be specified in the conformance 
  2422. test suite Recommendation*. 
  2423. .RT
  2424. .sp 1P
  2425. .LP
  2426. 6.4.2
  2427.     \fIRepeatability of results\fR 
  2428. .sp 9p
  2429. .RT
  2430. .PP
  2431. In order to achieve the objective of credible conformance testing, it is 
  2432. clear that the result of executing a test case on an IUT should be the 
  2433. same whenever it is performed. Statistically, it may not be possible to 
  2434. perform a complete conformance test suite and observe outcomes which are 
  2435. completely 
  2436. identical to those obtained on another occasion: unforeseen events do occur,
  2437. and this is a feature of the environments involved. Nevertheless, at the 
  2438. test case level, it is very important that every effort is made by the 
  2439. test 
  2440. specifiers and test laboratories to minimize the possibility that a test 
  2441. case produces different outcomes on different occasions. 
  2442. .bp
  2443. .RT
  2444. .sp 1P
  2445. .LP
  2446. 6.4.3
  2447.     \fIComparability of results\fR 
  2448. .sp 9p
  2449. .RT
  2450. .PP
  2451. In order to achieve the ultimate objectives of conformance testing, the 
  2452. overall summary concerning conformance of an IUT has to be independent 
  2453. of the test environment in which the testing takes place. That is to say, 
  2454. the 
  2455. standardization of all of the procedures concerned with conformance testing
  2456. should result in a comparable overall summary being accorded to the IUT,
  2457. whether the testing is done by the supplier, a user, or by any third party 
  2458. test house. There are a large number of factors to be studied to achieve 
  2459. this, of 
  2460. which some of the more important are:
  2461. .RT
  2462. .LP
  2463.     a)
  2464.     careful design of the abstract test case specification to
  2465. give flexibility where appropriate, but show which
  2466. requirements have to be met (which is the subject of this
  2467. Recommendation);
  2468. .LP
  2469.     b)
  2470.     careful specification of the real tester which should be
  2471. used to run the test suite; again this specification should give flexibility
  2472. where appropriate, but show which requirements have to be met, including all
  2473. test coordination procedures (if any);
  2474. .LP
  2475.     c)
  2476.     careful specification of the procedure to be followed in
  2477. determining how the contents of the PICS are to be used in the analysis of
  2478. outcomes of test cases; there should be no room for \*Qoptimistic\*U
  2479. interpretation;
  2480. .LP
  2481.     d)
  2482.     careful specification of the procedures to be followed by
  2483. test laboratories as regards the repetition of a test case before making a
  2484. final verdict for that test purpose;
  2485. .LP
  2486.     e)
  2487.     a proforma for a conformance test report;
  2488. .LP
  2489.     f
  2490. )
  2491.     careful specification of the procedures necessary
  2492. when synthesizing an overall summary.
  2493. .sp 1P
  2494. .LP
  2495. 6.4.4
  2496.     \fIAuditability of results\fR 
  2497. .sp 9p
  2498. .RT
  2499. .PP
  2500. For legal reasons, as well as others, it may be necessary to
  2501. review the observed outcomes from the execution of a conformance test suite 
  2502. in order to make sure that all procedures have been correctly followed. 
  2503. Whether or not analysis has been carried out in a manual or automatic mode, 
  2504. it is 
  2505. essential that all inputs, outputs, and other test events are careful logged, 
  2506. and the analysis of the results recorded. In some cases this may be the 
  2507. responsibility of the test realizer, who may elect to include the test 
  2508. criteria in the conformance log, as well as all outcomes. In others, it 
  2509. may be the 
  2510. responsibility of the test laboratory, which might be required to follow all
  2511. standard procedures concerning the recording of results.
  2512. .PP
  2513. \fINote\fR \ \(em\ As far as auditability is concerned, some automatic
  2514. procedures would be preferred, but in the event it should be appreciated 
  2515. that from a legal standpoint such automatic procedures would have to be 
  2516. accredited themselves, if they are to be credible. 
  2517. .RT
  2518. .sp 2P
  2519. .LP
  2520. \fB7\fR     \fBTest methods\fR 
  2521. .sp 1P
  2522. .RT
  2523. .sp 1P
  2524. .LP
  2525. 7.1
  2526.     \fIIntroduction\fR 
  2527. .sp 9p
  2528. .RT
  2529. .PP
  2530. The testing of a given OSI* protocol can require the use of
  2531. several test methods, as systems under test can come in several configurations, 
  2532. and vary in terms of their ability to allow ways of producing effects 
  2533. applicable to a layer boundary.
  2534. .PP
  2535. This section first characterizes the features of the system under
  2536. test which are to be taken into consideration, next defines the possible 
  2537. test methods in abstract terms, and finally provides guidance on their 
  2538. applicability to real systems. 
  2539. .RT
  2540. .LP
  2541. 7.2
  2542.     \fIClassification of real open systems and IUTs for conformance\fR 
  2543. \fItesting\fR 
  2544. .sp 1P
  2545. .RT
  2546. .sp 2P
  2547. .LP
  2548. 7.2.1
  2549.     \fIClassification of systems under test\fR 
  2550. .sp 1P
  2551. .RT
  2552. .PP
  2553. 7.2.1.1
  2554. There is a relation between the test methods and the
  2555. configurations of the real open systems to be tested. The appropriate test
  2556. methods vary according to:
  2557. .sp 9p
  2558. .RT
  2559. .LP
  2560.     a)
  2561.     the main function of the system (end\(hysystem or
  2562. relay\(hysystem);
  2563. .LP
  2564.     b)
  2565.     which layers use OSI* protocols;
  2566. .LP
  2567.     c)
  2568.     whether the alternative of non\(hyOSI* protocols is
  2569. also available.
  2570. .bp
  2571. .PP
  2572. 7.2.1.2 
  2573. The following configurations of systems have been
  2574. identified for the purposes of conformance testing, as illustrated in
  2575. Figures\ 2/X.290 to\ 4/X.290, Part\ 1. Configurations 1 to 3 are the basic
  2576. configurations of systems under test (SUTs):
  2577. .sp 9p
  2578. .RT
  2579. .LP
  2580.     a)
  2581.     Configuration\ 1: 7\(hylayer open system (end\(hysystem)
  2582. .LP
  2583.     These systems use OSI* Recommendation* protocols in
  2584. all 7 layers.
  2585. .LP
  2586.     b)
  2587.     Configuration\ 2: Partial (N)\(hyopen system (end\(hysystem)
  2588. .LP
  2589.     These systems use OSI* Recommendation* protocols in
  2590. layers 1 to N.
  2591. .LP
  2592.     c)
  2593.     Configuration\ 3: Open relay\(hysystems
  2594. .LP
  2595.     These use OSI* protocols in layers 1 to 3 (Network
  2596. relay\(hysystems) or 1 to 7 (Application
  2597. relay\(hysystems).
  2598. .LP
  2599. .rs
  2600. .sp 15P
  2601. .ad r
  2602. \fBFigures 2/X.290, partie 1 \*`a 4/X.290, partie 1, (N), p.\fR 
  2603. .sp 1P
  2604. .RT
  2605. .ad b
  2606. .RT
  2607. .PP
  2608. 7.2.1.3 
  2609. Other configurations can be derived from the basic
  2610. configurations.
  2611. .sp 9p
  2612. .RT
  2613. .PP
  2614. A SUT can be a combination of basic configurations\ 1 and\ 2,
  2615. allowing the alternative of using OSI* and non\(hyOSI* protocols above layer\ N
  2616. (see Figure\ 5/X.290, Part\ 1).
  2617. .LP
  2618. .rs
  2619. .sp 15P
  2620. .ad r
  2621. \fBFigure 5/X.290, partie 1, (N), p.\fR 
  2622. .sp 1P
  2623. .RT
  2624. .ad b
  2625. .RT
  2626. .LP
  2627. .bp
  2628. .sp 1P
  2629. .LP
  2630. 7.2.2
  2631.     \fIIdentification of the implementation under test (IUT)\fR 
  2632. .sp 9p
  2633. .RT
  2634. .PP
  2635. An implementation under test (IUT) is that part of a real open
  2636. system which is to be studied by conformance testing. It should be an
  2637. implementation of one or more adjacent OSI* protocols.
  2638. .PP
  2639. IUTs can be defined for configurations 1 and 2 of SUTs as single\(hylayer 
  2640. IUTs (one single layer of the SUT is to be tested), or as multi\(hylayer 
  2641. IUTs (a set of any number of adjacent layers of the SUT to be tested in 
  2642. combination).
  2643. .PP
  2644. An IUT defined in an open relay\(hysystem will include at least the
  2645. layer which provides the relay function.
  2646. .PP
  2647. When OSI* and non\(hyOSI* protocols exist in a system, the IUT(s) will 
  2648. be defined for the OSI* mode(s) of operation. Testing non\(hyOSI* protocols 
  2649. is 
  2650. outside the scope of this Recommendation.
  2651. .PP
  2652. Clients and test laboratories will agree on what part of the SUT
  2653. will be considered to be the IUT.
  2654. .RT
  2655. .sp 1P
  2656. .LP
  2657. 7.3
  2658.     \fIAbstract testing methodology\fR \ \(em\ \fIGeneral\fR 
  2659. .sp 9p
  2660. .RT
  2661. .PP
  2662. \fR Test methods need to refer to an abstract testing methodology,
  2663. based upon the OSI reference model. Considering first end\(hysystems (7\(hylayer 
  2664. or partial (N)\(hyopen systems) and single layer IUTs within these systems, 
  2665. abstract test methods are described in terms of what outputs from the IUT 
  2666. are observed and what inputs to it can be controlled. More specifically, 
  2667. an abstract test 
  2668. method is described by identifying the points closest to the IUT at which
  2669. control and observation are to be exercized.
  2670. .PP
  2671. The OSI* protocol Recommendations* define allowed behaviour of a
  2672. protocol entity (i.e.\ the dynamic conformance requirements) in terms of the
  2673. protocol data units (PDUs) and the abstract service primitives (ASPs) both
  2674. above and below that entity. Thus the behaviour of an (N)\(hyASPs and (N\ 
  2675. \(em\ 1)\(hyASPs (the latter including the (N)\(hyPDUs). 
  2676. .PP
  2677. If an IUT comprises more than one protocol entity, the required
  2678. behaviour can be defined in terms of the ASPs above and below the IUT,
  2679. including the PDUs of the protocols in the IUT.
  2680. .PP
  2681. The starting point for developing test methods is the conceptual
  2682. testing architecture, illustrated in Figure\ 6/X.290, Part\ 1. It is a
  2683. \*Qblack\(hybox\*U active testing architecture, based on the definition 
  2684. of behaviour required of the IUT. 
  2685. .PP
  2686. The action of the tester shown in Figure 6/X.290, Part\ 1, can either be 
  2687. applied 
  2688. locally, in which case there is a direct coupling within the system under 
  2689. test, or externally via a link or network. The two sets of interactions, 
  2690. above and 
  2691. below the IUT, can, in practice, be observed and controlled from several
  2692. different points, locally or externally.
  2693. .PP
  2694. The possible points of control and observation (PCOs) are
  2695. identified by three factors:
  2696. .RT
  2697. .LP
  2698.     a)
  2699.     whether it is the ASPs or PDUs which are observed and
  2700. controlled;
  2701. .LP
  2702.     b)
  2703.     the layer identity of the ASPs or PDUs concerned;
  2704. .LP
  2705.     c)
  2706.      whether they are controlled and observed within the system under test 
  2707. or in a system remote from the system under test \(em if the latter 
  2708. then the ASPs are distinguished by the addition of a double\(hyquote
  2709. character\ (\|\*U\|).
  2710. .LP
  2711. .rs
  2712. .sp 14P
  2713. .ad r
  2714. \fBFigure 6/X.290, partie 1, (N), p.\fR 
  2715. .sp 1P
  2716. .RT
  2717. .ad b
  2718. .RT
  2719. .LP
  2720. .bp
  2721. .PP
  2722. Possible PCOs within the SUT are illustrated in
  2723. Figure\ 7a)/X.290, Part\ 1. Possible PCOs, when the activity below the IUT is
  2724. controlled and observed externally are illustrated in Figure\ 7b)/X.290,
  2725. Part\ 1. It can be seen from these figures that there is a multiplicity of
  2726. possible PCOs in different layers, which offer different degrees of control 
  2727. and observation of IUT behaviour. This Recommendation makes a selection 
  2728. from this set of possible PCOs, defining a limited number of abstract test 
  2729. methods.
  2730. .LP
  2731. .rs
  2732. .sp 14P
  2733. .ad r
  2734. \fBFigure 7a/X.290, partie 1, (N), p.\fR 
  2735. .sp 1P
  2736. .RT
  2737. .ad b
  2738. .RT
  2739. .LP
  2740. .rs
  2741. .sp 14P
  2742. .ad r
  2743. \fBFigure 7b/X.290, partie 1, (N), p.\fR 
  2744. .sp 1P
  2745. .RT
  2746. .ad b
  2747. .RT
  2748. .PP
  2749. If control and observation below, or external from the IUT is
  2750. specified in terms of ASPs, it will include control and observation of 
  2751. the PDUs carried by those ASPs; but if it is specified in terms of PDUs 
  2752. (at layer\ N) 
  2753. then the ASPs (at layer\ N\ \(em\ 1) are not considered to be controlled or
  2754. observed.
  2755. .PP
  2756. It is assumed that the ASP activity below the IUT can at least be
  2757. observable and controllable via the peer activity in a remote testing system 
  2758. \(em i.e.\ the corresponding ASP\*Us. Thus when the ASPs below the IUT 
  2759. are not 
  2760. controllable nor observable locally, conformance testing can be carried out
  2761. externally, provided that the underlying service offered is sufficiently
  2762. reliable for control and observation to take place remotely.
  2763. .PP
  2764. It is possible that the ASP activity above the IUT might not be
  2765. controllable nor observable, in which case this activity is said to be
  2766. hidden.
  2767. .PP
  2768. SUTs are not required to provide access to layer boundaries. However, the 
  2769. possible provision of such access and the possible positions of such 
  2770. boundaries with respect to the layers of the IUT are factors to be taken 
  2771. into consideration in the definition of the test methods, which may take 
  2772. advantage of this access to define the test suites in terms of the corresponding 
  2773. ASPs. It does not matter whether the accessible boundaries are accessed 
  2774. via service 
  2775. access points (SAPs) or via some other PCOs.
  2776. .bp
  2777. .PP
  2778. Figure 8/X.290, Part\ 1 shows examples of IUTs, with respect to layer boundary 
  2779. accessibility. 
  2780. .PP
  2781. \fINote\fR \ \(em\ In addition, a conformance test suite Recommendation*\fR 
  2782. may define \*Uabstract local primitives\*U. These are used to specify control 
  2783. and observation of events or states which are referred to in the protocol 
  2784. Recommendation* but which are internal to the IUT and which cannot be
  2785. expressed in terms of ASPs. They are abbreviations for text descriptions of
  2786. control and observation to be performed by the upper tester.
  2787. .PP
  2788. Similar consideration apply to relay systems (see Part 2 of the
  2789. Recommendation for details).
  2790. .RT
  2791. .LP
  2792. .rs
  2793. .sp 15P
  2794. .ad r
  2795. \fBFigure 8/X.290, partie 1, (N), p.\fR 
  2796. .sp 1P
  2797. .RT
  2798. .ad b
  2799. .RT
  2800. .sp 1P
  2801. .LP
  2802. 7.4
  2803.     \fIAbstract testing functions\fR 
  2804. .sp 9p
  2805. .RT
  2806. .PP
  2807. The definition of abstract test methods requires that the PCOs be distributed 
  2808. over two abstract testing functions, the lower and upper testers. 
  2809. .PP
  2810. The lower tester is the abstraction of the means of providing,
  2811. during test execution, control and observation at the appropriate PCO either
  2812. below the IUT or remote from the IUT, as defined by the chosen abstract test
  2813. method. Thus, it is the testing function related to the control
  2814. and observation of the lower boundary of the IUT. If the action of the 
  2815. tester is local to the SUT, the lower tester will take the place of the 
  2816. lower part of the SUT. If the action of the tester is external to the SUT, 
  2817. the lower tester will rely on the (N\ \(em\ 1)\(hyService, provided jointly 
  2818. by the lower tester itself, a link and the SUT. 
  2819. .PP
  2820. The upper tester is the abstraction of the means of providing,
  2821. during test execution, control and observation of the upper service boundary 
  2822. of the IUT and of any relevant abstract local primitive. 
  2823. .PP
  2824. There is a need for cooperation between the upper tester and the
  2825. lower tester; the rules for such cooperation are called the test coordination 
  2826. procedures. 
  2827. .PP
  2828. The test methods will vary in the way that they specify the test
  2829. coordination procedures. In some cases it is possible to define a test
  2830. management protocol to provide the coordination between the upper and lower
  2831. testers. In other cases it is only possible to describe the requirements 
  2832. to be met by the test coordination procedures without specifying what mechanisms 
  2833. might be used to realize them.
  2834. .RT
  2835. .sp 2P
  2836. .LP
  2837. 7.5
  2838.     \fIOverview of abstract test methods\fR 
  2839. .sp 1P
  2840. .RT
  2841. .sp 1P
  2842. .LP
  2843. 7.5.1
  2844.     \fIEnd\(hysystem IUTs\fR 
  2845. .sp 9p
  2846. .RT
  2847. .PP
  2848. For the IUTs defined within end\(hysystem SUTs (configurations\ 1 and 2 
  2849. in Figures\ 2/X.290, Part\ 1 and\ 3/X.290, Part\ 1) four categories of 
  2850. abstract 
  2851. test methods are defined, one local, and three external ones which assume 
  2852. the lower tester is located remotely from the SUT and connected to it by 
  2853. a link or network. 
  2854. .bp
  2855. .RT
  2856. .sp 1P
  2857. .LP
  2858. 7.5.2
  2859.     \fIThe local test methods\fR 
  2860. .sp 9p
  2861. .RT
  2862. .PP
  2863. The local abstract test methods define the PCOs as being at the
  2864. service boundaries above and below the IUT. The test events are specified in
  2865. terms of the ASPs above the IUT and the ASPs and PDUs below the IUT, as
  2866. illustrated in Figure\ 9a)/X.290, Part\ 1. Abstractly, a lower tester is
  2867. considered to observe and control the ASPs and PDUs below the IUT, while an
  2868. upper tester observes and controls the ASPs above the IUT. Requirements 
  2869. to be met by test coordination procedures used to coordinate the realizations 
  2870. of the upper and lower testers are defined in the abstract conformance 
  2871. test suites, 
  2872. although the test coordination procedures themselves are not.
  2873. .RT
  2874. .sp 1P
  2875. .LP
  2876. 7.5.3
  2877.     \fIExternal test methods\fR 
  2878. .sp 9p
  2879. .RT
  2880. .PP
  2881. The external test methods use control and observation of the ASPs below 
  2882. the IUT by means of a lower tester separated from the SUT, together with 
  2883. control and observation of the ASPs above the IUT. Three different categories 
  2884. of external abstract test methods are defined, which are referred to as 
  2885. distributed, coordinated, and remote. They vary according to the level of
  2886. requirement or standardization put on the test coordination procedures, on
  2887. the access to the layer boundary above the IUT, and on the requirements on
  2888. an upper tester. They are illustrated in Figures\ 9b), c) and\ d)/X.290,
  2889. Part\ 1.
  2890. .PP
  2891. The coordinated test method requires that the test coordination
  2892. procedures used to coordinate the realization of the upper and lower testers 
  2893. be achieved by means of test management protocols. The other two methods 
  2894. do not make any assumptions about the realization of the test coordination 
  2895. procedures.
  2896. .PP
  2897. The distributed and coordinated test methods require specific
  2898. functions from the upper tester above the IUT. The remote method
  2899. does not.
  2900. .PP
  2901. The distributed method requires access to the upper boundary of
  2902. the IUT. The other two methods do not.
  2903. .RT
  2904. .LP
  2905. .rs
  2906. .sp 29P
  2907. .ad r
  2908. \fBFigure 9/X.290, partie 1, (N), p.\fR 
  2909. .sp 1P
  2910. .RT
  2911. .ad b
  2912. .RT
  2913. .LP
  2914. .bp
  2915. .sp 1P
  2916. .LP
  2917. 7.5.4
  2918.     \fIVariants of end\(hysystem test methods\fR 
  2919. .sp 9p
  2920. .RT
  2921. .PP
  2922. Each category of test methods has variants which can be applied
  2923. to single\(hylayer IUTs or to multi\(hylayer IUTs. For multi\(hylayer IUTs 
  2924. in which 
  2925. the protocols are to be tested layer by layer, embedded variants can be
  2926. used.
  2927. .PP
  2928. All abstract test methods for end\(hysystems are fully specified in
  2929. section\ 8 of Part\ 2 of this Recommendation, including their single\(hylayer,
  2930. multi\(hylayer and embedded variants where applicable.
  2931. .RT
  2932. .sp 1P
  2933. .LP
  2934. 7.5.5
  2935.     \fIRelay\(hysystem IUTs\fR 
  2936. .sp 9p
  2937. .RT
  2938. .PP
  2939. For open relay\(hysystems, two test methods are defined, loop\(hyback
  2940. and transverse. These are fully specified in section\ 8 of Part\ 2 of this
  2941. Recommendation.
  2942. .RT
  2943. .sp 1P
  2944. .LP
  2945. 7.6
  2946.     \fIApplicability of test methods to real open systems\fR 
  2947. .sp 9p
  2948. .RT
  2949. .PP
  2950. The architecture and stage of development of a real open system
  2951. determines the applicability of test methods to it.
  2952. .PP
  2953. Local test methods are useful for systems under development, when
  2954. their architecture permits the isolation of an IUT, be it single\(hylayer or
  2955. multi\(hylayer.
  2956. .PP
  2957. External test methods are useful for testing complete or partial
  2958. end\(hysystems which can attach to telecommunications networks.
  2959. .PP
  2960. Coordinated test methods apply where it is possible to implement a
  2961. standardized test management protocol in an upper tester in the SUT, above 
  2962. the IUT. 
  2963. .PP
  2964. Remote test methods apply when it is possible to make use of some
  2965. functions of the SUT to control the IUT during testing, instead of using a
  2966. specific upper tester.
  2967. .PP
  2968. Distributed test methods apply when it is necessary to allow
  2969. complete freedom for the implementation of the test coordination procedures
  2970. between the SUT and the lower tester, but to specify in detail the control 
  2971. and observation requirements at both ends. 
  2972. .PP
  2973. Single\(hylayer test methods are the most appropriate methods for testing 
  2974. the majority of the protocol conformance requirements. 
  2975. .PP
  2976. Multi\(hylayer test methods will be used when conformance to true
  2977. multi\(hylayer dynamic conformance requirements is to be tested.
  2978. .PP
  2979. Embedded test methods permit the application of single\(hylayer
  2980. testing to all layers of a multi\(hylayer IUT.
  2981. .PP
  2982. For 7\(hylayer open systems, the preferred methods are the
  2983. incremental use of appropriate external single\(hylayer embedded methods 
  2984. with the following PCOs: 
  2985. .RT
  2986. .LP
  2987.     a)
  2988.     the upper interface of the application layer as provided
  2989. by the 7\(hylayer open system, when applicable;
  2990. .LP
  2991.     b)
  2992.      successively, each SAP (or corresponding PCO if there is no SAP as such) 
  2993. below the protocol which is the focus of the 
  2994. testing, as controlled and observed in the external
  2995. lower tester, starting from the lowest protocol of the IUT
  2996. and working upwards.
  2997. .sp 1P
  2998. .LP
  2999. 7.7
  3000.     \fIApplicability of the test methods to OSI* protocols and layers\fR 
  3001. .sp 9p
  3002. .RT
  3003. .PP
  3004. The test methods defined in this Recommendation apply to all
  3005. layers, with the exception of the Physical layer and the Media Access Control 
  3006. protocols which are outside the scope of this Recommendation. Appendix\ 
  3007. I of 
  3008. this Recommendation provides guidance on the applicability of test methods 
  3009. to all other layers. 
  3010. .RT
  3011. .sp 2P
  3012. .LP
  3013. \fB8\fR     \fBTest suites\fR 
  3014. .sp 1P
  3015. .RT
  3016. .sp 1P
  3017. .LP
  3018. 8.1
  3019.     \fIStructure\fR 
  3020. .sp 9p
  3021. .RT
  3022. .PP
  3023. Test suites have a hierarchical structure (see Figure\ 10/X.290,
  3024. Part\ 1) in which an important level is the test case. Each test case has a
  3025. narrowly defined purpose, such as that of verifying that the IUT has a 
  3026. certain required capability (e.g.\ the ability to support certain packet 
  3027. sizes) or 
  3028. exhibit a certain required behaviour (e.g.\ behave as required when a particular 
  3029. event occurs in a particular state). 
  3030. .bp
  3031. .PP
  3032. Within a test suite, nested test groups are used to provide a logical ordering 
  3033. of the test cases. Test groups may be nested to an arbitrary depth. 
  3034. They may be used to aid planning, development, understanding or execution of
  3035. the test suite.
  3036. .PP
  3037. Test cases are modularized by using named subdivisions called test
  3038. steps. Each test case comprises at least one test step: the ordering of 
  3039. events covered by the test purpose (\*Utest body\*U). It may include further 
  3040. test steps to put the IUT into the state required for the test body to 
  3041. start from (the 
  3042. \*Upreamble\*U) or return to a quiescent state after the test body has finished
  3043. (the \*Upostamble\*U).
  3044. .PP
  3045. For practical reasons, common test steps may be grouped together
  3046. into test step libraries. Test step libraries may be structured into nested
  3047. sets of test steps, to any depth of nesting. Test step libraries may be
  3048. associated with the whole test suite or with a particular test group or test
  3049. case.
  3050. .PP
  3051. Furthermore, all test steps consist of an ordering of other test
  3052. steps andB/For test events (e.g.\ the transfer of a single PDU or ASP to 
  3053. or from the IUT). All test steps are, therefore, equivalent to an ordering 
  3054. of test 
  3055. events (after expansion of the inner test steps).
  3056. .RT
  3057. .LP
  3058. .rs
  3059. .sp 38P
  3060. .ad r
  3061. \fBFigure 10/X.290, partie 1, (N), p.\fR 
  3062. .sp 1P
  3063. .RT
  3064. .ad b
  3065. .RT
  3066. .LP
  3067. .bp
  3068. .sp 2P
  3069. .LP
  3070. 8.2
  3071.     \fIGeneric, abstract and executable test cases\fR 
  3072. .sp 1P
  3073. .RT
  3074. .PP
  3075. 8.2.1 
  3076. A generic test case is one which:
  3077. .sp 9p
  3078. .RT
  3079. .LP
  3080.     a)
  3081.     provides a refinement of the test purpose;
  3082. .LP
  3083.     b)
  3084.     specifies that all sequences of test events (paths)
  3085. in the test body which correspond to verdicts of \*Qpass\*U, \*Qfail\*U and
  3086. \*Qinconclusive\*U, using a specialized notation;
  3087. .LP
  3088.     c)
  3089.     is used as the common root of corresponding abstract test
  3090. cases for different abstract test suites for the
  3091. same protocol;
  3092. .LP
  3093.     d)
  3094.     includes a description of the initial state in which the
  3095. test body should start, in lieu of a preamble;
  3096. .LP
  3097.     e)
  3098.     need not describe the postamble;
  3099. .LP
  3100.     f
  3101. )
  3102.      is specified using the style of either the Remote or Distributed Single\(hylayer 
  3103. test methods. 
  3104. .PP
  3105. 8.2.2 
  3106. An abstract test case is derived from a generic case and the
  3107. relevant protocol specification; it:
  3108. .sp 9p
  3109. .RT
  3110. .LP
  3111.     a)
  3112.     specifies the test case in terms of a particular test
  3113. method;
  3114. .LP
  3115.     b)
  3116.     adds a more precise specification for sequences of events
  3117. which are only described informally in the generic
  3118. test case;
  3119. .LP
  3120.     c)
  3121.     adds the sequences of test events required to achieve the
  3122. objectives of the preamble and postamble of the generic test case using a
  3123. specialized notation.
  3124. .PP
  3125. 8.2.3
  3126. An executable test case is derived from an abstract test case,
  3127. and is in a form which allows it to be run on a real tester for testing 
  3128. a real implementation. 
  3129. .sp 9p
  3130. .RT
  3131. .PP
  3132. 8.2.4
  3133. The terms generic, abstract and executable are used to
  3134. describe test suites, which comprise generic, abstract and executable test
  3135. cases, respectively.
  3136. .sp 9p
  3137. .RT
  3138. .PP
  3139. 8.2.5
  3140. A generic test suite has the coverage of the set or a
  3141. superset of all possible abstract test suites for a particular
  3142. protocol.
  3143. .sp 9p
  3144. .RT
  3145. .sp 2P
  3146. .LP
  3147. \fB9\fR     \fBRelationships between concepts and roles\fR 
  3148. .sp 1P
  3149. .RT
  3150. .PP
  3151. Figure\ 11/X.290, Part\ 1 is a pictorial representation of the
  3152. relation between the various Recommendations and the processes of producing
  3153. generic, abstract and executable test suites and test reports.
  3154. .PP
  3155. Part\ 2 concerns the production of testable protocol
  3156. Recommendations and abstract test suite Recommendations. Part\ 1 provides
  3157. general concepts and definitions.
  3158. .PP
  3159. \fINote\fR \ \(em\ Other aspects of the conformance assessment process, 
  3160. such as executable test derivation, preparation of the IUT, PICS and PIXIT 
  3161. by the 
  3162. client and test laboratory role are for further study.
  3163. .RT
  3164. .sp 2P
  3165. .LP
  3166. \fB10\fR     \fBCompliance\fR 
  3167. .sp 1P
  3168. .RT
  3169. .PP
  3170. In this Recommendation, \*Qcompliance\*U refers to meeting the
  3171. requirements specified by the Recommendation. This word is used as an
  3172. attempt to eliminate confusion between \fIcompliance\fR to this Recommendation
  3173. and \fIconformance\fR of a protocol implementation to protocol
  3174. Recommendations.
  3175. .PP
  3176. This part of the Recommendation contains no compliance
  3177. requirements.
  3178. .RT
  3179. .LP
  3180. .rs
  3181. .sp 06P
  3182. .ad r
  3183. BLANC
  3184. .ad b
  3185. .RT
  3186. .LP
  3187. .bp
  3188. .LP
  3189. .rs
  3190. .sp 47P
  3191. .ad r
  3192. \fBFigure 11/X.290, partie 1, (N), p. 10\fR 
  3193. .sp 1P
  3194. .RT
  3195. .ad b
  3196. .RT
  3197. .LP
  3198. .bp
  3199. .sp 1P
  3200. .ce 1000
  3201. \fBPart\ 2\ \(em\ \fR \fBAbstract test suite specification\fR 
  3202. .sp 1P
  3203. .RT
  3204. .ce 0
  3205. .sp 1P
  3206. .sp 2P
  3207. .LP
  3208. \fB0\fR     \fBIntroduction\fR 
  3209. .sp 1P
  3210. .RT
  3211. .PP
  3212. This part of the Recommendation provides a common approach to the specification 
  3213. of \*QOSI or related CCITT X\(hyseries or T\(hyseries\*U (hereafter 
  3214. abbreviated to \*QOSI*\*U) conformance test suites at a level which is
  3215. independent of the means of executing those test suites (hereafter called
  3216. \*Qabstract test suites\*U). This level of abstraction is suitable for
  3217. standardization and facilitates the comparison of results produced by different 
  3218. organizations which run the corresponding executable test suites. 
  3219. .PP
  3220. Section One recalls that there are requirements put on the OSI*
  3221. protocol specifiers which have to be fulfilled before there can be an objective 
  3222. basis for the process of developing an abstract test suite. The need for 
  3223. consistent conformance sections and for PICS and PIXIT proformas in OSI*
  3224. protocol Recommendations* is expressed.
  3225. .PP
  3226. Section Two describes the process of developing an abstract test
  3227. suite, including the design criteria to be used and guidance on its structure 
  3228. and coverage. The possible abstract test methods are defined and guidance 
  3229. is 
  3230. given to help the test suite specifier to decide which method(s) to use 
  3231. in the production of a particular test suite. The relationship between 
  3232. abstract test suites for different methods is provided by a generic test 
  3233. suite which is 
  3234. independent of the test method. A test notation is defined and requirements 
  3235. and guidance are given on its use for specifying both generic and abstract 
  3236. test 
  3237. cases. These include the subdivision of test cases into test steps and the
  3238. assignment of verdicts to outcomes.
  3239. .PP
  3240. The test suite specifier is also required to provide information
  3241. to the test realizers, particularly on the constraints governing test case
  3242. selection and ordering.
  3243. .PP
  3244. Finally, guidance and requirements are given on test suite
  3245. maintenance.
  3246. .RT
  3247. .sp 2P
  3248. .LP
  3249. \fB1\fR     \fBScope and field of application\fR 
  3250. .sp 1P
  3251. .RT
  3252. .PP
  3253. This part of the Recommendation specifies the requirements and
  3254. provides guidance for the production of system\(hyindependent conformance test
  3255. suites for one or more OSI* Recommendations*. In particular, it applies 
  3256. to the production of all conformance test suite Recommendations* for OSI* 
  3257. protocols. 
  3258. .PP
  3259. It applies to the production of conformance test cases which check
  3260. the adherence of an implementation to the relevant static and/or dynamic
  3261. conformance requirements by controlling and observing protocol behaviour. 
  3262. The abstract test methods included in this Recommendation are in fact capable 
  3263. of 
  3264. being used to specify any test case which can be expressed abstractly in 
  3265. terms of control and observation of protocol data units, abstract service 
  3266. primitives and abstract local primitives. Nevertheless, for some protocols, 
  3267. test cases may be needed which cannot be expressed in these terms. The 
  3268. specification of such test cases is outside the scope of this Recommendation, 
  3269. although those test 
  3270. cases may need to be included in a Recommendation* for a conformance test
  3271. suite.
  3272. .PP
  3273. \fINote\fR \ \(em\ For example, some static conformance requirements related 
  3274. to an application service may require testing techniques which are specific 
  3275. to 
  3276. that particular application.
  3277. .PP
  3278. The production of conformance test suites for multi\(hypeer or
  3279. physical layer protocols is outside the scope of this
  3280. Recommendation.
  3281. .PP
  3282. The relation between abstract test specification and formal
  3283. description techniques is outside the scope of this
  3284. Recommendation.
  3285. .RT
  3286. .sp 2P
  3287. .LP
  3288. \fB2\fR     \fBReferences\fR 
  3289. .sp 1P
  3290. .RT
  3291. .sp 1P
  3292. .LP
  3293. Recommendation\ X.200
  3294.      \fIReference model of open systems interconnection\fR \fIfor CCITT applications\fR 
  3295. \| 
  3296. (see also ISO\ 7498).
  3297. .sp 9p
  3298. .RT
  3299. .LP
  3300. Recommendation\ X.214
  3301.     \fITransport service definition for open systems\fR 
  3302. \fIinterconnection for CCITT applications\fR \|
  3303. (see also ISO\ 8072).
  3304. .LP
  3305. Recommendation\ X.224
  3306.     \fITransport protocol specification for open\fR 
  3307. \fIsystems interconnection for CCITT applications\fR \|
  3308. (see also ISO\ 8073).
  3309. .bp
  3310. .LP
  3311. Recommendation\ X.210
  3312.     \fIOpen systems interconnection layer service\fR 
  3313. \fIdefinition conventions\fR \|
  3314. (see also ISO\ TR\ 8509).
  3315. .LP
  3316. Recommendation\ X.208
  3317.     \fISpecification of abstract syntax notation one\fR 
  3318. \fI(ASN.1)\fR \|
  3319. (see also ISO\ 8824).
  3320. .LP
  3321. Recommendation\ X.209
  3322.      \fISpecification of basic encoding rules for abstract\fR \fIsyntax notation 
  3323. one (ASN.1)\fR \| 
  3324. (see also ISO\ 8825).
  3325. .LP
  3326. Recommendation\ X.290/1
  3327.     \fIOSI conformance testing methodology and\fR 
  3328. \fIframework for protocol Recommendations for CCITT applications\ \(em\ 
  3329. Part\ 1:\fR 
  3330. \fIGeneral concepts.\fR 
  3331. .LP
  3332. ISO\ 8571\(hy4
  3333.     \fIInformation processing systems\ \(em\ open systems\fR 
  3334. \fIinterconnection\ \(em\ File protocol specification.\fR 
  3335. .sp 2P
  3336. .LP
  3337. \fB3\fR     \fBDefinitions\fR 
  3338. .sp 1P
  3339. .RT
  3340. .PP
  3341. For the purposes of this Part of the Recommendation, all the
  3342. definitions in Part\ 1 of the Recommendation apply.
  3343. .RT
  3344. .sp 2P
  3345. .LP
  3346. \fB4\fR     \fBAbbreviations\fR 
  3347. .sp 1P
  3348. .RT
  3349. .PP
  3350. For the purposes of this Recommendation the abbreviations given in section\ 
  3351. 4 of Part\ 1 of this Recommendation apply. The following abbreviations 
  3352. also apply to this Recommendation: 
  3353. .RT
  3354. .LP
  3355.     ASP\*U
  3356.     the abstract service primitive on the side of the service
  3357. provider remote from the IUT
  3358. .LP
  3359.     CM
  3360.     coordinated multi\(hylayer (test method)
  3361. .LP
  3362.     CS
  3363.     coordinated single\(hylayer (test method)
  3364. .LP
  3365.     CSE 
  3366.     coordinated single\(hylayer embedded (test method)
  3367. .LP
  3368.     DM
  3369.     distributed multi\(hylayer (test method)
  3370. .LP
  3371.     DS
  3372.     distributed single\(hylayer (test method)
  3373. .LP
  3374.     DSE 
  3375.     distributed single\(hylayer embedded (test method)
  3376. .LP
  3377.     FDT 
  3378.     formal description technique
  3379. .LP
  3380.     LM
  3381.     local multi\(hylayer (test method)
  3382. .LP
  3383.     LS
  3384.     local single\(hylayer (test method)
  3385. .LP
  3386.     LSE 
  3387.     local single\(hylayer embedded (test method)
  3388. .LP
  3389.     RM
  3390.     remote multi\(hylayer (test method)
  3391. .LP
  3392.     RS
  3393.     remote single\(hylayer (test method)
  3394. .LP
  3395.     RSE 
  3396.     remote single\(hylayer embedded (test method)
  3397. .LP
  3398.     TTCN
  3399.     tree and tabular combined notation
  3400. .LP
  3401.     YL
  3402.     loop\(hyback (test method)
  3403. .LP
  3404.     YT
  3405.     transverse (test method)
  3406. .sp 2P
  3407. .LP
  3408. \fB5\fR     \fBCompliance\fR 
  3409. .sp 1P
  3410. .RT
  3411. .PP
  3412. 5.1
  3413. A protocol Recommendation* which complies with this Part of
  3414. this Recommendation shall satisfy all the requirements stated in
  3415. Section\ 1.
  3416. .sp 9p
  3417. .RT
  3418. .PP
  3419. \fINote\fR \ \(em\ Such compliance is a precondition for the
  3420. protocol Recommendation* to be an effective basis for conformance testing of
  3421. implementations.
  3422. .PP
  3423. 5.2
  3424. An abstract test suite specification which complies with this part of this 
  3425. Recommendation: 
  3426. .sp 9p
  3427. .RT
  3428. .LP
  3429.     a)
  3430.     shall be a conformance test suite;
  3431. .LP
  3432.     b)
  3433.     shall be specified in a test notation standardized by
  3434. ISO or CCITT;
  3435. .LP
  3436.     c)
  3437.     shall satisfy all the requirements stated in
  3438. Section\ 2.
  3439. .PP
  3440. 5.3
  3441. It is recommended that the test notation used be the Tree and Tabular Combined 
  3442. Notation (TTCN). If TTCN is used, the abstract test suite 
  3443. shall comply with all the requirements in Annex\ D.
  3444. .bp
  3445. .sp 9p
  3446. .RT
  3447. .sp 1P
  3448. .ce 1000
  3449. SECTION\ 1\ \(em\ \fIRequirements on protocol specifiers\fR 
  3450. .sp 1P
  3451. .RT
  3452. .ce 0
  3453. .sp 1P
  3454. .sp 2P
  3455. .LP
  3456. \fB6\fR     \fBConformance requirements in OSI* Recommendations*\fR 
  3457. .sp 1P
  3458. .RT
  3459. .sp 1P
  3460. .LP
  3461. 6.1
  3462.     \fIIntroduction\fR 
  3463. .sp 9p
  3464. .RT
  3465. .PP
  3466. The meaning of conformance in OSI* is discussed in Part\ 1 of this Recommendation. 
  3467. It is necessary that there be an unambiguous and objective 
  3468. understanding of the conformance requirements of an OSI* protocol or transfer 
  3469. syntax Recommendation*, as a prerequisite to the production of an abstract 
  3470. test suite for that Recommendation*. This section states the requirements 
  3471. on 
  3472. protocol specifiers to ensure that there is such an understanding
  3473. of the conformance requirements.
  3474. .RT
  3475. .sp 2P
  3476. .LP
  3477. 6.2
  3478.     \fIGeneral requirements\fR 
  3479. .sp 1P
  3480. .RT
  3481. .PP
  3482. 6.2.1
  3483. A clear distinction shall be made between static and dynamic
  3484. conformance requirements. To avoid ambiguity, they should be stated separately 
  3485. from one another. 
  3486. .sp 9p
  3487. .RT
  3488. .PP
  3489. 6.2.2
  3490. It shall be clear what conformance to the Recommendation*
  3491. means, in the sense of what shall be done, what is permitted but not mandatory, 
  3492. and what shall not be implemented, to conform to the Recommendation*. 
  3493. .sp 9p
  3494. .RT
  3495. .PP
  3496. 6.2.3
  3497. It shall always be decidable whether an instance of
  3498. communication conforms dynamically or not.
  3499. .sp 9p
  3500. .RT
  3501. .PP
  3502. For example, one should be able to look at a record of PDU
  3503. activity and decide whether it is valid.
  3504. .PP
  3505. 6.2.4
  3506. Requirements on the need to produce and content of a PICS
  3507. shall be stated separately from the requirements on the protocol implementation 
  3508. itself. 
  3509. .sp 9p
  3510. .RT
  3511. .sp 2P
  3512. .LP
  3513. 6.3
  3514.     \fIConformance sections\fR 
  3515. .sp 1P
  3516. .RT
  3517. .PP
  3518. 6.3.1
  3519. Each OSI* protocol and transfer syntax Recommendation* shall
  3520. include a conformance section, which shall be expressed clearly and
  3521. unambiguously.
  3522. .sp 9p
  3523. .RT
  3524. .PP
  3525. 6.3.2
  3526. Conformance sections shall distinguish between the following
  3527. categories of information that they may contain:
  3528. .sp 9p
  3529. .RT
  3530. .LP
  3531.     a)
  3532.     references to sections which state dynamic conformance
  3533. requirements;
  3534. .LP
  3535.     b)
  3536.     static conformance requirements concerning the protocol
  3537. implementation;
  3538. .LP
  3539.     c)
  3540.     static conformance requirements concerning multi\(hylayer
  3541. dependencies;
  3542. .LP
  3543.     d)
  3544.     what has to be stated in the PICS concerning (b) above;
  3545. .LP
  3546.     e)
  3547.     what has to be stated in the PICS concerning (c) above;
  3548. .LP
  3549.     f
  3550. )
  3551.     what other information shall be provided
  3552. (e.g. to assist testing) and whether this should be in the PICS or
  3553. elsewhere.
  3554. .PP
  3555. 6.3.3
  3556. In connection\(hyoriented protocol Recommendations*, the
  3557. conformance section should also include:
  3558. .sp 9p
  3559. .RT
  3560. .LP
  3561.     a)
  3562.     the option to support either the initiation of a
  3563. connection or the acceptance of a connection, or both;
  3564. .LP
  3565.     b)
  3566.     the requirement to be able to accept all correct sequences
  3567. of PDUs received from peers, and respond with correct PDU
  3568. sequences appropriate to the defined state of the
  3569. connection;
  3570. .LP
  3571.     c)
  3572.     the requirement to be able to respond correctly to all
  3573. incorrect sequences of PDUs received, the response being
  3574. appropriate to the defined state of the
  3575. connection.
  3576. .bp
  3577. .sp 1P
  3578. .LP
  3579. 6.4
  3580.     \fIAdditional guidance for new protocol Recommendations*\fR 
  3581. .sp 9p
  3582. .RT
  3583. .PP
  3584. It is recognized that although existing protocol Recommendations* can be 
  3585. improved by the progression of an addendum to add a PICS proforma and 
  3586. make the conformance section align with the requirements stated above, it is
  3587. unrealistic to expect any greater improvement. However, new protocol
  3588. Recommendations* should be developed using the additional guidance given in
  3589. Annex\ B to make the task of understanding the conformance requirements 
  3590. easier and less prone to ambiguity. 
  3591. .RT
  3592. .LP
  3593. \fB7\fR     \fBPICS proformas\fR 
  3594. .sp 1P
  3595. .RT
  3596. .sp 2P
  3597. .LP
  3598. 7.1
  3599.     \fIRequirements on PICS proformas\fR 
  3600. .sp 1P
  3601. .RT
  3602. .PP
  3603. 7.1.1
  3604. The specific requirements to be met by suppliers in respect
  3605. of each PICS they provide shall normally be stated in the relevant protocol
  3606. Recommendation*. The specification of these requirements shall include
  3607. a PICS proforma. In exceptional circumstances, the PICS proforma may be 
  3608. found in the abstract test suite Recommendation* rather than in protocol 
  3609. Recommendation*; in particular, this applies when the PICS proforma has
  3610. to cover different versions of the same protocol coming from both ISO and
  3611. CCITT. In normal circumstances, the PICS proforma should be found in an 
  3612. annex to the protocol Recommendation* and referenced in the conformance 
  3613. section, and, if necessary, progressed as an addendum rather than as part of
  3614. the original Recommendation*.
  3615. .sp 9p
  3616. .RT
  3617. .PP
  3618. \fINote\fR \ \(em\ A PICS for a specific protocol implementation will need 
  3619. to be accompanied by administrative and documentary information relating 
  3620. to the supplier, the system and its intended environment. 
  3621. .PP
  3622. 7.1.2
  3623. The PICS proforma shall be in the form of a questionnaire or
  3624. checklist to be completed by the supplier or implementor of an implementation 
  3625. of the relevant OSI* protocol. 
  3626. .sp 9p
  3627. .RT
  3628. .PP
  3629. 7.1.3
  3630. The PICS proforma shall cover all functions, elements of
  3631. procedure, parameters, options, PDUs, timers, multi\(hylayer dependencies and
  3632. other capabilities identified in the protocol Recommendation*, including
  3633. optional and conditional capabilities. It is desirable, where practicable, 
  3634. to include all mandatory features. There shall be a well\(hydefined mapping 
  3635. between static conformance requirements and the PICS proforma and there 
  3636. shall be 
  3637. consistency between them.
  3638. .sp 9p
  3639. .RT
  3640. .PP
  3641. 7.1.4
  3642. The PICS proforma shall be preceded by a section that
  3643. states:
  3644. .sp 9p
  3645. .RT
  3646. .LP
  3647.     \*QThe supplier of a protocol implementation which is claimed to
  3648. conform to this Recommendation shall complete the following Protocol
  3649. Implementation Conformance Statements (PICS) proforma and shall
  3650. provide the information necessary to identify uniquely both the
  3651. supplier and the implementation.\*U
  3652. .PP
  3653. 7.1.5
  3654. The name, version and date of the relevant protocol
  3655. Recommendation* shall be stated on each page of the PICS proforma.
  3656. .sp 9p
  3657. .RT
  3658. .PP
  3659. 7.1.6
  3660. The PICS proforma for a specific protocol shall
  3661. contain:
  3662. .sp 9p
  3663. .RT
  3664. .LP
  3665.     a)
  3666.     explanations of special symbols, abbreviations, special
  3667. terms, together with appropriate references;
  3668. .LP
  3669.     b)
  3670.     explicit instructions for completing and interpreting the
  3671. PICS;
  3672. .LP
  3673.     c)
  3674.     provision for mentioning any mandatory feature that has
  3675. not been implemented, with the appropriate rationale;
  3676. .LP
  3677.     d)
  3678.     one or more tables (or other kinds of form as necessary)
  3679. to be completed to state the capabilities of the implementation
  3680. in detail, including:
  3681. .LP
  3682.     1)
  3683.     name of the feature, PDU type, timer, parameter, and
  3684. other capabilities;
  3685. .LP
  3686.     2)
  3687.     a column stating whether each is mandatory, optional,
  3688. negotiable, or conditional;
  3689. .LP
  3690.     3)
  3691.     wherever feasible, a column giving references to the
  3692. relevant sections in the Recommendation;
  3693. .LP
  3694.     4)
  3695.     a column giving the permitted range or values, if
  3696. appropriate;
  3697. .LP
  3698.     5)
  3699.     a column to be filled in to give the supported
  3700. values or range of values, if appropriate;
  3701. .LP
  3702.     6)
  3703.     a column to be filled in to state if each capability
  3704. has been implemented;
  3705. .LP
  3706.     e)
  3707.     the proforma shall give a clear indication of the
  3708. preferred data types (e.g.\ number bases, string types, octets,
  3709. bits, seconds, minutes,\ etc.) for responses.
  3710. .bp
  3711. .PP
  3712. 7.1.7
  3713. The PICS proforma shall use the following abbreviations as
  3714. appropriate, unless they conflict with the abbreviations used in the specific 
  3715. protocol Recommendation*: 
  3716. .sp 9p
  3717. .RT
  3718. .LP
  3719.     m
  3720.     mandatory
  3721. .LP
  3722.     o
  3723.     optional
  3724. .LP
  3725.     c
  3726.     conditional
  3727. .LP
  3728.     n
  3729.     negotiable (using the protocol)
  3730. .LP
  3731.     x
  3732.     exclusion of capability
  3733. .LP
  3734.     \(em
  3735.     not applicable
  3736. .LP
  3737.     s
  3738.     ability to send
  3739. .LP
  3740.     r
  3741.     ability to receive
  3742. .sp 1P
  3743. .LP
  3744. 7.2
  3745.     \fIGuidance on PICS proformas\fR 
  3746. .sp 9p
  3747. .RT
  3748. .PP
  3749. Appendix\ III provides some general purpose examples to give
  3750. guidance on the construction of PICS proformas.
  3751. .RT
  3752. .LP
  3753. .rs
  3754. .sp 38P
  3755. .ad r
  3756. BLANC
  3757. .ad b
  3758. .RT
  3759. .LP
  3760. .bp
  3761. .sp 1P
  3762. .ce 1000
  3763. SECTION\ 2\ \(em\ \fIRequirements on abstract test suite specifiers\fR 
  3764. .sp 1P
  3765. .RT
  3766. .ce 0
  3767. .sp 1P
  3768. .sp 2P
  3769. .LP
  3770. \fB8\fR     \fBTest suite production process\fR 
  3771. .sp 1P
  3772. .RT
  3773. .PP
  3774. In order to present the requirements and general guidance for
  3775. abstract test suite specification, it is useful to assume a normal form 
  3776. of the process of test suite production. This section describes the process 
  3777. in just 
  3778. such a normal form. Abstract test suite specifiers are not required to 
  3779. follow this normal form exactly, however, they are recommended to use a 
  3780. similar 
  3781. process involving the same steps, possibly in a different order.
  3782. .PP
  3783. For the purposes of this Recommendation, the abstract test suite
  3784. production process is assumed to be as follows:
  3785. .RT
  3786. .LP
  3787.     a)
  3788.     study the relevant Recommendation(s)* to determine
  3789. what the conformance requirements (including options) are which
  3790. need to be tested, and what needs to be stated in the PICS
  3791. (see\ \(sc\ 9);
  3792. .LP
  3793.     b)
  3794.     decide on the test groups which will be needed to achieve
  3795. the appropriate coverage of the conformance requirements and
  3796. refine the test groups into sets of test purposes
  3797. (see\ \(sc\ 10);
  3798. .LP
  3799.     c)
  3800.     specify generic test cases for each test purpose, using
  3801. some appropriate test notation (see\ \(sc\ 11);
  3802. .LP
  3803.     d)
  3804.     choose the test method(s) for which the complete abstract
  3805. test cases need to be specified, and decide what restrictions
  3806. need to be placed on the capabilities of the lower tester and
  3807. [if appropriate to the chosen test method(s)] the
  3808. upper tester and test coordination procedures
  3809. (see\ \(sc\ 12);
  3810. .LP
  3811.     e)
  3812.     choose the test notation for specifying the complete
  3813. abstract test cases, and specify the complete abstract test
  3814. cases, including the test step structure to be used
  3815. (see\ \(sc\ 13);
  3816. .LP
  3817.     f
  3818. )
  3819.     specify the inter\(hyrelationships among the test cases
  3820. and those between the test cases and the PICS and, as far as
  3821. possible, the PIXIT, in order to determine the restrictions
  3822. on the selection and parameterization of test cases for
  3823. execution, and on the order in which they can be executed
  3824. (see\ \(sc\ 14);
  3825. .LP
  3826.     g)
  3827.     consider the procedures for maintaining the abstract test
  3828. suite (see\ \(sc\ 15).
  3829. .PP
  3830. The remainder of this section provides requirements and guidance which 
  3831. relate to each step in the above process. 
  3832. .sp 2P
  3833. .LP
  3834. \fB9\fR     \fBDetermining the conformance requirements and PICS\fR 
  3835. .sp 1P
  3836. .RT
  3837. .sp 1P
  3838. .LP
  3839. 9.1
  3840.     \fIIntroduction\fR 
  3841. .sp 9p
  3842. .RT
  3843. .PP
  3844. Before an abstract test suite can be specified, the test suite
  3845. specifier shall first determine what the conformance requirements are for 
  3846. the relevant Recommendation(s)* and what is stated in the PICS proforma 
  3847. concerning the implementation of those Recommendation(s)*. 
  3848. .RT
  3849. .sp 1P
  3850. .LP
  3851. 9.2
  3852.     \fIConformance requirements\fR 
  3853. .sp 9p
  3854. .RT
  3855. .PP
  3856. Section\ 1 of this part of the Recommendation specifies the
  3857. requirements to be met by protocol specifiers as a prerequisite to the
  3858. production of an abstract test suite for a particular protocol.
  3859. .PP
  3860. In practice, early OSI* Recommendations* might not contain a clear
  3861. specification of all the relevant conformance requirements. In particular, 
  3862. the static conformance requirements might be badly specified or even omitted. 
  3863. In 
  3864. such cases, the test suite specifier shall contribute to the production 
  3865. of an amendment or addendum to the relevant Recommendation(s)* to clarify 
  3866. the 
  3867. conformance requirements. If, however, an abstract test suite has to be
  3868. produced in advance of the conformance requirements being clarified in the
  3869. relevant Recommendation(s)*, then the test suite specifier shall adopt the
  3870. short\(hyterm solution given in Annex\ C and state clearly in the test suite
  3871. Recommendation* what the implications of this are (i.e.\ what is assumed 
  3872. to be mandatory, what conditional and what the conditions are, and what 
  3873. is assumed to be optional). 
  3874. .bp
  3875. .RT
  3876. .sp 1P
  3877. .LP
  3878. 9.3
  3879.     \fIPICS proforma\fR 
  3880. .sp 9p
  3881. .RT
  3882. .PP
  3883. If no PICS proforma is included in a relevant protocol
  3884. Recommendation*, the test suite specifier shall provide a PICS proforma 
  3885. to be processed as an addendum to that Recommendation*, or in exceptional 
  3886. circumstances (as discussed in \(sc\ 7.1.1) as an annex to the abstract 
  3887. test suite Recommendation*. 
  3888. .PP
  3889. \fINote\fR \ \(em\ Progressing an addendum to an existing protocol
  3890. Recommendation* may well be faster than progressing the abstract test
  3891. suite Recommendation* because the PICS proforma is likely to be less
  3892. controversial than the test suite and therefore is likely to require fewer
  3893. revisions before a final text can be agreed.
  3894. .RT
  3895. .sp 2P
  3896. .LP
  3897. \fB10\fR     \fBTest suite structure\fR 
  3898. .sp 1P
  3899. .RT
  3900. .sp 1P
  3901. .LP
  3902. 10.1
  3903.     \fIBasic requirements\fR 
  3904. .sp 9p
  3905. .RT
  3906. .PP
  3907. An abstract test suite shall comprise a number of test cases. The test 
  3908. cases shall be grouped into test groups, if necessary nested. The 
  3909. structure shall be hierarchical in the sense that an item at a lower level
  3910. shall be completely contained within a higher level item. The structure need
  3911. not, however, be strictly hierarchical in the sense that any one test case 
  3912. may occur in more than one test suite or test group. Similar test groups 
  3913. may occur in more than one higher level test group or test suite. 
  3914. .PP
  3915. The abstract test suite specifier shall ensure that a subset of the
  3916. test purposes of each abstract test suite is concerned with capability 
  3917. testing, and another subset is concerned with behaviour testing. This need 
  3918. not lead to distinct test cases for behaviour and capability testing because 
  3919. it may be 
  3920. possible to use the same test steps for both a behaviour test purpose and 
  3921. for a capability test purpose. The test suite specifier shall provide an 
  3922. explanation of how the test purposes are derived from or relate to the 
  3923. protocol 
  3924. Recommendation*. The test suite specifier shall also provide a summary 
  3925. of the coverage achieved by the test suite. 
  3926. .RT
  3927. .sp 1P
  3928. .LP
  3929. 10.2
  3930.     \fIThe test group structure\fR 
  3931. .sp 9p
  3932. .RT
  3933. .PP
  3934. In order to ensure that the resulting abstract test suite provides adequate 
  3935. coverage of the relevant conformance requirements, the test suite 
  3936. specifier is advised to design the test suite structure in terms of nested 
  3937. test groups in a top down manner (see Figure\ 1/X.290, Part\ 2). 
  3938. .PP
  3939. There are many ways of structuring the same test suite into test
  3940. groups; no one way is necessarily right and the best approach for one test
  3941. suite may not be appropriate for another test suite. Nevertheless, the test
  3942. suite specifier shall ensure that the test suite includes test cases for
  3943. whichever of the following categories is relevant:
  3944. .RT
  3945. .LP
  3946.     a)
  3947.     capability tests (for static conformance requirements);
  3948. .LP
  3949.     b)
  3950.     behaviour tests of valid behaviour;
  3951. .LP
  3952.     c)
  3953.     behaviour tests of syntactically invalid behaviour;
  3954. .LP
  3955.     d)
  3956.     behaviour tests of inopportune behaviour;
  3957. .LP
  3958.     e)
  3959.     tests focusing on PDUs sent to the IUT;
  3960. .LP
  3961.     f
  3962. )
  3963.     tests focusing on PDUs received from the IUT;
  3964. .LP
  3965.     g)
  3966.     tests focusing on interactions between what is sent and
  3967. received;
  3968. .LP
  3969.     h)
  3970.     tests related to each protocol mandatory feature;
  3971. .LP
  3972.     i)
  3973.     tests related to each optional feature which is
  3974. implemented;
  3975. .LP
  3976.     j)
  3977.     tests related to each protocol phase;
  3978. .LP
  3979.     k)
  3980.     variations in the test event occurring in a particular
  3981. state;
  3982. .LP
  3983.     l)
  3984.     timing and timer variations;
  3985. .LP
  3986.     m)
  3987.     PDU encoding variations;
  3988. .LP
  3989.     n)
  3990.     variations in values of individual parameters;
  3991. .LP
  3992.     o)
  3993.     variations in combinations of parameter
  3994. values.
  3995. .bp
  3996. .PP
  3997. This list is not exhaustive; additional categories might be needed to ensure 
  3998. adequate coverage of the relevant conformance requirements for a 
  3999. specific test suite. Furthermore, these categories overlap one another 
  4000. and it is the task of the test suite specifier to put them into an appropriate 
  4001. hierarchical structure. The following structure is an example of a
  4002. single\(hylayer test suite, provided for guidance:
  4003. .LP
  4004.     A
  4005.     Capability tests
  4006. .LP
  4007.     A.1
  4008.     Mandatory features
  4009. .LP
  4010.     A.2
  4011.     Optional features said by the PICS to be
  4012. supported
  4013. .LP
  4014.     B
  4015.     Behaviour tests: response to valid behaviour by peer
  4016. implementation
  4017. .LP
  4018.     B.1
  4019.     Connection establishment phase (if relevant)
  4020. .LP
  4021.     B.1.1
  4022.     Focus on what is sent to the IUT
  4023. .LP
  4024.     B.1.1.1
  4025.     Test event variation in each
  4026. state
  4027. .LP
  4028.     B.1.1.2
  4029.     Timing/timer variation
  4030. .LP
  4031.     B.1.1.3
  4032.     Encoding variation
  4033. .LP
  4034.     B.1.1.4
  4035.     Individual parameter value
  4036. variation
  4037. .LP
  4038.     B.1.1.5
  4039.     Combination of parameter
  4040. values
  4041. .LP
  4042.     B.1.2
  4043.     Focus on what is received from the IUT
  4044. .LP
  4045.     \(em\ substructured as B.1.1
  4046. .LP
  4047.     B.1.3
  4048.     Focus on interactions
  4049. .LP
  4050.     \(em\ substructured as B.1.1
  4051. .LP
  4052.     B.2
  4053.     Data transfer phase
  4054. .LP
  4055.     \(em\ substructured as B.1
  4056. .LP
  4057.     B.3
  4058.     Connection release phase (if relevant)
  4059. .LP
  4060.     \(em\ substructured as B.1
  4061. .LP
  4062.     C
  4063.     Behaviour tests: response to syntactically invalid behaviour
  4064. by peer implementation
  4065. .LP
  4066.     C.1
  4067.     Connection establishment phase (if relevant)
  4068. .LP
  4069.     C.1.1
  4070.     Focus on what is sent to the IUT
  4071. .LP
  4072.     C.1.1.1
  4073.     Test event variation in each
  4074. state
  4075. .LP
  4076.     C.1.1.2
  4077.     Encoding variation of the
  4078. invalid event
  4079. .LP
  4080.     C.1.1.3
  4081.     Individual invalid parameter
  4082. value variation
  4083. .LP
  4084.     C.1.1.4
  4085.     Invalid parameter value
  4086. combination variation
  4087. .LP
  4088.     C.1.2
  4089.     Focus on what the IUT is requested to send
  4090. .LP
  4091.     C.1.2.1
  4092.     Individual invalid parameter
  4093. values
  4094. .LP
  4095.     C.1.2.2
  4096.     Invalid combinations of
  4097. parameter values
  4098. .LP
  4099.     C.2
  4100.     Data transfer phase
  4101. .LP
  4102.     \(em\ substructured as C.1
  4103. .LP
  4104.     C.3
  4105.     Connection release phase (if relevant)
  4106. .LP
  4107.     \(em\ substructured as C.1
  4108. .LP
  4109.     D
  4110.     Behaviour tests: response to inopportune events by peer
  4111. implementation
  4112. .LP
  4113.     D.1
  4114.     Connection establishment phase (if relevant)
  4115. .LP
  4116.     D.1.1
  4117.     Focus on what is sent to the IUT
  4118. .LP
  4119.     D.1.1.1
  4120.     Test event variation in each
  4121. state
  4122. .LP
  4123.     D.1.1.2
  4124.     Timing/timer variation
  4125. .LP
  4126.     D.1.1.3
  4127.     Special encoding variations
  4128. .LP
  4129.     D.1.1.4
  4130.     Major individual parameter
  4131. value variations
  4132. .LP
  4133.     D.1.1.5
  4134.     Variation in major combination
  4135. of parameter values
  4136. .LP
  4137.     D.1.2
  4138.     Focus on what is requested to be sent by
  4139. the IUT
  4140. .LP
  4141.     \(em\ substructured as D.1.1
  4142. .LP
  4143.     D.2
  4144.     Data transfer phase
  4145. .LP
  4146.     \(em\ substructured as D.1
  4147. .LP
  4148.     D.3
  4149.     Connection release phase (if relevant)
  4150. .LP
  4151.     \(em\ substructured as D.1
  4152. .bp
  4153. .PP
  4154. If the test suite is to cover more than one layer, then a
  4155. single\(hylayer test suite structure such as this could be replicated for each
  4156. layer concerned. In addition, a correspondingly detailed structure could be
  4157. produced for testing the capabilities and behaviour of multiple layers taken
  4158. as a whole, including the interaction between the activities in adjacent
  4159. layers.
  4160. .sp 1P
  4161. .LP
  4162. 10.3
  4163.     \fITest purposes\fR 
  4164. .sp 9p
  4165. .RT
  4166. .PP
  4167. The test suite specifier shall ensure that, for each test case in an abstract 
  4168. test suite, there is a clear statement of the test purpose. It is suggested 
  4169. that these test purposes should be produced as the next refinement of the 
  4170. test suite, after its structure in terms of test groups has been defined. 
  4171. The test purposes could be produced directly from studying those sections 
  4172. in 
  4173. the relevant Recommendation(s)* which are appropriate to the test group
  4174. concerned. For some test groups, the test purposes might be derivable directly 
  4175. from the protocol state table; for others, they might be derivable from 
  4176. the PDU encoding definitions or the descriptions of particular parameters, 
  4177. or from text which specifies the relevant conformance requirements. Alternatively, 
  4178. the test suite specifier could employ a formal description of the protocol(s) 
  4179. concerned and derive test purposes from that by means of some automated 
  4180. method. 
  4181. .PP
  4182. Whatever method is used to derive the test purposes, the test
  4183. suite specifier shall ensure that they provide an adequate coverage of the
  4184. conformance requirements of the Recommendation(s)* concerned. There
  4185. shall be at least one test purpose related to each distinct conformance
  4186. requirement.
  4187. .PP
  4188. In addition, it is possible to give guidance on the meaning of
  4189. \*Qadequate coverage\*U with reference to the above example. In order to 
  4190. express 
  4191. this, a shorthand notation will be used: the letter \*Qx\*U will represent all
  4192. appropriate values for the first digit in the test group identifier, and
  4193. similarly \*Qy\*U for the second digit, so that B.x.y.1 stands for B.1.1.1,
  4194. B.1.2.1, B.1.3.1, B.2.1.1, B.2.2.1, B.2.3.1, B.3.1.1, B.3.2.1 and\ B.3.3.1. 
  4195. With this notation, a minimum \*Qadequate coverage\*U for the above example 
  4196. is 
  4197. considered to be as follows:
  4198. .RT
  4199. .LP
  4200.     a)
  4201.     for capability test groups (A.1, A.2):
  4202. .LP
  4203.     1)
  4204.     at least one test purpose per relevant feature, class
  4205. or subset;
  4206. .LP
  4207.     2)
  4208.     at least one test purpose per relevant PDU type and
  4209. each major variation of each such type, using \*Qnormal\*U or
  4210. default values for each parameter;
  4211. .LP
  4212.     b)
  4213.     for test groups concerned with test event variation in
  4214. each state (B.x.y.1, C.x.1.1, D.x.y.1):
  4215. .LP
  4216.     \(em
  4217.     at least one test purpose per relevant state/event
  4218. combination;
  4219. .LP
  4220.     c)
  4221.     for test groups concerned with timers and timing (B.x.y.2,
  4222. D.x.y.2):
  4223. .LP
  4224.     1)
  4225.     at least one test purpose concerned with the expiry
  4226. of each defined timer;
  4227. .LP
  4228.     2)
  4229.     at least one test purpose concerned with very rapid
  4230. response for each relevant type of PDU;
  4231. .LP
  4232.     3)
  4233.     at least one test purpose concerned with very slow
  4234. response for each relevant type of PDU;
  4235. .LP
  4236.     d)
  4237.     for test groups concerned with encoding variations
  4238. (B.x.y.3, C.x.1.2, D.x.y.3):
  4239. .LP
  4240.     \(em
  4241.     at least one test purpose for each relevant kind of
  4242. encoding variation per relevant PDU type;
  4243. .LP
  4244.     e)
  4245.     for test groups concerned with valid individual parameter
  4246. values (B.x.y.4, D.x.y.4):
  4247. .LP
  4248.     1)
  4249.     for each relevant integer parameter, test purposes
  4250. concerned with the boundary values and one randomly
  4251. selected mid\(hyrange value;
  4252. .LP
  4253.     2)
  4254.     for each relevant bitwise parameter, test purposes
  4255. for as many values as practical, but not less than all the
  4256. \*Qnormal\*U or common values;
  4257. .LP
  4258.     3)
  4259.     for other relevant parameters, at least one test
  4260. purpose concerned with a value different from what is
  4261. considered \*Qnormal\*U or default in other test
  4262. groups;
  4263. .LP
  4264.     f
  4265. )
  4266.     for test groups concerned with invalid individual
  4267. parameter values (C.x.1.3, C.x.2.1):
  4268. .LP
  4269.     1)
  4270.     for each relevant integer parameter, test purposes
  4271. concerned with invalid values adjacent to the allowed
  4272. boundary values plus one other randomly selected invalid
  4273. value;
  4274. .LP
  4275.     2)
  4276.     for each relevant bitwise parameter, test purposes
  4277. for as many invalid values as practical;
  4278. .LP
  4279.     3)
  4280.     for all other relevant types of parameter, at least
  4281. one test purpose per parameter;
  4282. .bp
  4283. .LP
  4284.     g)
  4285.     for test groups concerned with combinations of parameter
  4286. values (B.x.y.5, C.x.1.4, C.x.2.2, D.x.y.5):
  4287. .LP
  4288.     1)
  4289.     at least one test purpose per \*Qcritical\*U value
  4290. pair;
  4291. .LP
  4292.     2)
  4293.     at least one test purpose per pair of interrelated
  4294. parameters to test a random combination of relevant
  4295. values.
  4296. .sp 2P
  4297. .LP
  4298. \fB11\fR     \fBGeneric test case specification\fR 
  4299. .sp 1P
  4300. .RT
  4301. .sp 1P
  4302. .LP
  4303. 11.1
  4304.     \fIIntroduction\fR 
  4305. .sp 9p
  4306. .RT
  4307. .PP
  4308. The test suite specifier is recommended to specify a generic test suite, 
  4309. particularly if there is an intention to produce more than one abstract 
  4310. test suite. 
  4311. .PP
  4312. A generic test suite shall consist of one generic test case for
  4313. each test purpose. Each generic test case will be a refinement of its test
  4314. purpose, which can be used as a common root of corresponding abstract test
  4315. cases for different test methods.
  4316. .PP
  4317. If a generic test suite is produced in advance of abstract test
  4318. suites, then it will be a useful step in the design process. If the generic
  4319. test suite is produced after the production of at least one abstract test
  4320. suite, then it will provide a means of relating different test suites
  4321. to one another and analyzing where there may be gaps in their
  4322. coverage.
  4323. .RT
  4324. .sp 1P
  4325. .LP
  4326. 11.2
  4327.     \fIDescription of generic test cases\fR 
  4328. .sp 9p
  4329. .RT
  4330. .PP
  4331. A generic test case consists of a test description of an \*Qinitial state\*U 
  4332. [of the test body] and a specification of the test body in a 
  4333. standardized test notation. The \*Qinitial state\*U includes not only the 
  4334. protocol state, but also any necessary information concerning the state 
  4335. of the SUT and the testing environment. 
  4336. .PP
  4337. The test body is that part of a test case in which verdicts
  4338. related to the test purpose are assigned to foreseen outcomes. The test
  4339. body:
  4340. .RT
  4341. .LP
  4342.     a)
  4343.     shall be defined in the style of either the Remote or
  4344. Distributed test method;
  4345. .LP
  4346.     \fINote\fR \ \(em\ Generic test cases may use the full expressive
  4347. power of these methods (see \(sc\ 12.3.3 for details), including the
  4348. use of abstract local primitives.
  4349. .LP
  4350.     b)
  4351.     shall assign verdicts to all possible outcomes; all
  4352. outcomes yielding \*Qpass\*U verdicts shall be explicitly
  4353. identified, whereas all outcomes yielding \*Qfail\*U or
  4354. \*Qinconclusive\*U verdicts shall be either identified or
  4355. categorized (which may include categorization of default
  4356. verdicts);
  4357. .LP
  4358.     c)
  4359.     shall be described using a standardized test notation; the
  4360. Tree and Tabular Combined Notation (TTCN) (defined in Annex\ D)
  4361. is recommended.
  4362. .sp 1P
  4363. .LP
  4364. 11.3
  4365.     \fIRelation of generic to abstract test cases\fR 
  4366. .sp 9p
  4367. .RT
  4368. .PP
  4369. For a particular abstract test method there may be many abstract
  4370. test cases that can be derived from a single generic test case. A major
  4371. difference between an abstract test case and a generic test case is that the
  4372. abstract test case includes specifications of a preamble and a postamble. 
  4373. The preamble starts from a chosen stable state and leads to the required 
  4374. initial 
  4375. state of the test body. The postamble starts from the end of the test body 
  4376. and returns to a chosen stable state. 
  4377. .PP
  4378. The preamble and postamble may be realized in different ways
  4379. depending on the degree of control and observation provided by the test 
  4380. method used, or on the variety of different possible stable states which 
  4381. the derived abstract test case can start from and end in. These abstract 
  4382. test cases are 
  4383. simply different ways of achieving the same test purpose.
  4384. .PP
  4385. In addition, the test body of an abstract test case may be different from 
  4386. the corresponding generic test case if the test method used for the 
  4387. abstract test case is different from that used for the generic
  4388. test case.
  4389. .PP
  4390. If a generic test suite is produced, it shall be used as the means
  4391. of relating corresponding abstract test suites for different abstract test
  4392. methods.
  4393. .bp
  4394. .RT
  4395. .sp 2P
  4396. .LP
  4397. \fB12\fR     \fBAbstract test methods\fR 
  4398. .sp 1P
  4399. .RT
  4400. .sp 1P
  4401. .LP
  4402. 12.1
  4403.     \fIIntroduction\fR 
  4404. .sp 9p
  4405. .RT
  4406. .PP
  4407. Each abstract test suite shall be specified in terms of the control and 
  4408. observation of events in accordance with one of the abstract test methods 
  4409. defined in this section. The chosen test method determines the points at 
  4410. which control and observation shall be specified and the categories of 
  4411. events which shall be used [e.g.\ (N\ \(em\ 1)\(hyASPs, (N)\(hyPDUs]. 
  4412. .RT
  4413. .sp 2P
  4414. .LP
  4415. 12.2
  4416.     \fIGeneral specification of the abstract test methods\fR 
  4417. .sp 1P
  4418. .RT
  4419. .sp 1P
  4420. .LP
  4421. 12.2.1
  4422.     \fIEnd\(hysystem IUTs\fR 
  4423. .sp 9p
  4424. .RT
  4425. .PP
  4426. For IUTs within end\(hysystem SUTs there are four categories of
  4427. abstract test methods, one local, and three external ones which assume the
  4428. lower tester is located remotely from the SUT and connected to it by a 
  4429. link or network. 
  4430. .PP
  4431. For generality, the test methods are described with reference to
  4432. an IUT in which the highest layer is numbered \*QN\dt\u\*U (for \*Qtop\*U) 
  4433. and in 
  4434. which the lowest layer protocol to be tested is numbered \*QN\db\u\*U (for
  4435. \*Qbottom\*U). The IUT may implement protocols in layers lower than \*QN\db\u\*U, 
  4436. but these are not of interest in the test method descriptions. The description 
  4437. applies to single\(hylayer IUTs by taking N\dt\uto be equal to 
  4438. N\db\u.
  4439. .RT
  4440. .sp 1P
  4441. .LP
  4442. 12.2.2
  4443.     \fIAbstract local primitives\fR 
  4444. .sp 9p
  4445. .RT
  4446. .PP
  4447. Abstract test suite specifiers may, if necessary, define a set of abstract 
  4448. local primitives (ALPs) to be used in specifying the test suite. An 
  4449. ALP is an abbreviation for a description of control and/or observation to be
  4450. performed by the upper tester, which cannot be described in terms of ASPs 
  4451. but which initiate events or state changes defined within the relevant 
  4452. protocol 
  4453. Recommendation(s)*. ALPs may be used with any abstract test method for
  4454. end\(hysystem IUTs, but, for simplicity, will not be shown in any of the 
  4455. figures which illustrate those methods. 
  4456. .PP
  4457. Any test case which uses an ALP shall be optional in the abstract
  4458. test suite.
  4459. .RT
  4460. .sp 1P
  4461. .LP
  4462. 12.2.3
  4463.     \fIThe local test methods\fR 
  4464. .sp 9p
  4465. .RT
  4466. .PP
  4467. \fIAbbreviation: L\fR 
  4468. .PP
  4469. In this method:
  4470. .RT
  4471. .LP
  4472.     a)
  4473.     the abstract test suite is specified in terms of control
  4474. and observation of (N\db\u\ \(em\ 1)\(hyASPs and (N\db\u) to
  4475. (N\dt\u)\(hyPDUs;
  4476. .LP
  4477.     b)
  4478.     the abstract test suite is also specified in terms of
  4479. control and observation of (N\dt\u)\(hyASPs;
  4480. .LP
  4481.     c)
  4482.     the abstract test suite may also be specified in terms of
  4483. control and observation by the upper tester of abstract
  4484. local primitives (ALPs);
  4485. .LP
  4486.     d)
  4487.     the method requires access to the lower and upper
  4488. boundaries of the IUT and a mapping between the specified ASPs
  4489. and their realization within the SUT;
  4490. .LP
  4491.     e)
  4492.     the requirements for the test coordination procedures are
  4493. specified in the abstract test suite but no assumption is made
  4494. regarding their realization;
  4495. .LP
  4496.     f
  4497. )
  4498.     the upper and lower testers are required to achieve
  4499. control and observation of the specified ASPs and the required
  4500. test coordination procedures. They are assumed to be integrated
  4501. into the SUT.
  4502. .PP
  4503. This method is illustrated in Figure\ 1/X.290, Part\ 2.
  4504. .sp 2P
  4505. .LP
  4506. 12.2.4
  4507.     \fIExternal test methods\fR 
  4508. .sp 1P
  4509. .RT
  4510. .sp 1P
  4511. .LP
  4512. 12.2.4.1
  4513.     \fIThe distributed test method\fR 
  4514. .sp 9p
  4515. .RT
  4516. .PP
  4517. \fIAbbreviation: D\fR 
  4518. .PP
  4519. In this method:
  4520. .RT
  4521. .LP
  4522.     a)
  4523.     the abstract test suite is specified in terms of control
  4524. and observation of (N\db\u\ \(em\ 1)\(hyASP\*Us and (N\db\u) to
  4525. (N\dt\u)\(hyPDUs;
  4526. .bp
  4527. .LP
  4528.     b)
  4529.     the abstract test suite is also specified in terms of
  4530. control and observation of (N\dt\u)\(hyASPs; the method
  4531. requires access to the upper boundary of the IUT and a mapping
  4532. between the (N\dt\u)\(hyASPs and their realization within
  4533. the SUT;
  4534. .LP
  4535.     c)
  4536.     the abstract test suite may also be specified in terms of
  4537. control and observation by the upper tester of ALPs;
  4538. .LP
  4539.     d)
  4540.     the requirements for the test coordination procedures are
  4541. specified in the abstract test suite but no assumption is made
  4542. regarding their realization;
  4543. .LP
  4544.     e)
  4545.     the upper tester is required to achieve control and
  4546. observation of the specified (N\dt\u)\(hyASPs and to achieve
  4547. the effects of the required test coordination procedures; no
  4548. other assumptions are made;
  4549. .LP
  4550.     f
  4551. )
  4552.     the lower tester is required to achieve control and
  4553. observation of specified (N\db\u)\(hyASP\*Us and specified
  4554. PDUs and to achieve the required test coordination
  4555. procedures.
  4556. .PP
  4557. This method is illustrated in Figure\ 2/X.290, Part\ 2.
  4558. .sp 1P
  4559. .LP
  4560. 12.2.4.2
  4561.     \fIThe\fR 
  4562. \fIcoordinated test method\fR 
  4563. .sp 9p
  4564. .RT
  4565. .PP
  4566. \fIAbbreviation: C\fR 
  4567. .PP
  4568. In this method:
  4569. .RT
  4570. .LP
  4571.     a)
  4572.     the abstract test suite is specified in terms of control and
  4573. observation of (N\db\u\ \(em\ 1)\(hyASP\*Us, (N\db\u) to
  4574. (N\dt\u)\(hyPDUs and test management PDUs (TM\(hyPDUs);
  4575. .LP
  4576.     b)
  4577.     (N\dt\u)\(hyASPs need not be used in the specification
  4578. of the abstract test suite; no assumption is made about the
  4579. existence of an upper boundary of the IUT;
  4580. .LP
  4581.     c)
  4582.     the requirements for the test coordination procedures are
  4583. specified in the abstract test suite by means of a standardized
  4584. test management protocol;
  4585. .LP
  4586.     d)
  4587.     TM\(hyPDUs may be defined which correspond to ALPs;
  4588. .LP
  4589.     e)
  4590.     the upper tester is required to implement the test
  4591. management protocol and achieve the appropriate effects on the
  4592. IUT;
  4593. .LP
  4594.     f
  4595. )
  4596.     the lower tester is required to achieve control and
  4597. observation of specified (N\db\u)\(hyASP\*Us and specified
  4598. PDUs (including TM\(hyPDUs).
  4599. .PP
  4600. This method is illustrated in Figure\ 3/X.290, Part\ 2.
  4601. .sp 1P
  4602. .LP
  4603. 12.2.4.3
  4604.     \fIThe\fR 
  4605. \fIremote test method\fR 
  4606. .sp 9p
  4607. .RT
  4608. .PP
  4609. \fIAbbreviation: R\fR 
  4610. .PP
  4611. In this method, provision is made for the case where it is not
  4612. possible to observe and control the upper boundary of the IUT. Also in this
  4613. method:
  4614. .RT
  4615. .LP
  4616.     a)
  4617.     the abstract test suite is specified in terms of control
  4618. and observation of (N\db\u\ \(em\ 1)\(hyASP\*Us and (N\db\u) to
  4619. (N\dt\u)\(hyPDUs ;
  4620. .LP
  4621.     b)
  4622.     (N\dt\u)\(hyASPs are not used in the specification of
  4623. the abstract test suite; no assumption is made about the
  4624. existence of an upper boundary of the IUT;
  4625. .LP
  4626.     c)
  4627.     the abstract test suite may also be described in terms of
  4628. control and observation of ALPs within the SUT;
  4629. .LP
  4630.     d)
  4631.     some requirements for test coordination procedures may be
  4632. implied or informally expressed in the abstract test suite but
  4633. no assumption is made regarding their feasibility or
  4634. realization;
  4635. .LP
  4636.     e)
  4637.     abstractly the SUT needs to carry out some upper tester
  4638. functions to achieve whatever effects of test coordination
  4639. procedures and whatever control andB/For observation of the IUT
  4640. are implied, informally expressed or described by ALPs in the
  4641. abstract test suite for a given protocol; these functions are
  4642. not specified nor are any assumptions made regarding their
  4643. feasibility or realization;
  4644. .LP
  4645.     f
  4646. )
  4647.     the lower tester is required to achieve control and
  4648. observation of specified (N\db\u)\(hyASP\*Us and specified
  4649. PDUs and should attempt to achieve the implied or informally
  4650. expressed test coordination procedures in accordance with the
  4651. relevant information in the PIXIT.
  4652. .PP
  4653. This method is illustrated in Figure\ 4/X.290, Part\ 2.
  4654. .bp
  4655. .LP
  4656. .rs
  4657. .sp 29P
  4658. .ad r
  4659. \fBFigures 1, 2, 3 et 4/X.290, partie\ 2, (N), p.\fB
  4660. .sp 1P
  4661. .RT
  4662. .ad b
  4663. .RT
  4664. .sp 1P
  4665. .LP
  4666. 12.2.5
  4667.     \fISingle\(hylayer, multi\(hylayer and embedded variants\fR 
  4668. .sp 9p
  4669. .RT
  4670. .PP
  4671. Each category of test methods has a variant which can be applied
  4672. to single\(hylayer IUTs (abbreviation:\ S), and another which can be applied to
  4673. multi\(hylayer IUTs (abbreviation:\ M), when the set of adjacent layers 
  4674. is to be 
  4675. tested in combination (as a whole).
  4676. .PP
  4677. For a multi\(hylayer IUT in which the protocols are to be tested
  4678. layer by layer, an embedded variant of the test methods has been defined
  4679. (abbreviation:\ E).
  4680. .PP
  4681. If control and observation are applied to a means of access to the
  4682. upper boundary of the entities under test within SUT, then the test methods 
  4683. are normal (and no E is added to the abbreviated name). If, however, control 
  4684. and 
  4685. observation are applied through one or more OSI* layer entities above the
  4686. entities under test, the test methods are called embedded (and an\ E is 
  4687. appended to the abbreviated name). 
  4688. .PP
  4689. Names of particular variants of the test methods shall be formed
  4690. as follows:
  4691. .RT
  4692. .ce 1000
  4693. .sp 1
  4694. |
  4695. \ L\ 
  4696. |
  4697. .ce 0
  4698. .ce 1000
  4699. \ R\ 
  4700. .ce 0
  4701. .ce 1000
  4702. |
  4703. \ C\ 
  4704. |
  4705. .ce 0
  4706. .ce 1000
  4707. \ D\ 
  4708. |
  4709. \ S\ 
  4710. |
  4711. .ce 0
  4712. .PP
  4713. \ M\ 
  4714. [\ E\ ]
  4715. For example, DSE is the abbreviation for the \*Qdistributed
  4716. single embedded\*U test method.
  4717. .bp
  4718. .sp 1P
  4719. .LP
  4720. 12.2.6
  4721.     \fIOpen relay\(hysystems\fR 
  4722. .sp 9p
  4723. .RT
  4724. .PP
  4725. For open relay\(hysystems, loop\(hyback and transverse abstract test
  4726. methods are defined. They are given the abbreviated names: YL and YT,
  4727. respectively.
  4728. .RT
  4729. .sp 1P
  4730. .LP
  4731. 12.3
  4732.     \fISingle\(hylayer test methods for single\(hylayer IUTs in\fR 
  4733. \fIend\(hysystems\fR 
  4734. .sp 9p
  4735. .RT
  4736. .PP
  4737. For single\(hylayer test methods, the abstract model of the IUT is
  4738. called the (N)\(hyentity under test.
  4739. .RT
  4740. .sp 1P
  4741. .LP
  4742. 12.3.1
  4743.     \fIThe local single\(hylayer test method\fR 
  4744. .sp 9p
  4745. .RT
  4746. .PP
  4747. The Local Single\(hylayer (LS) abstract test method defines the points 
  4748. of control and observation as being at the service boundaries above and 
  4749. below the (N)\(hyentity under test. The test events are specified in terms 
  4750. of 
  4751. (N)\(hyASPs above the IUT, and (N\ \(em\ 1)\(hyASPs and (N)\(hyPDUs below
  4752. the IUT, as shown in Figure\ 5/X.290, Part\ 2. In addition, ALPs may be 
  4753. used as test events. Abstractly, a lower tester is considered to observe 
  4754. and control 
  4755. the (N\ \(em\ 1)\(hyASPs and (N)\(hyPDUs while an upper tester observes and
  4756. controls the (N)\(hyASPs and ALPs. The requirements to be met by test
  4757. coordination procedures used to coordinate the realizations of the upper and
  4758. lower testers are defined in the abstract test suites, although the test
  4759. coordination procedures themselves are not.
  4760. .RT
  4761. .sp 1P
  4762. .LP
  4763. 12.3.2
  4764.     \fIThe distributed single\(hylayer test method\fR 
  4765. .sp 9p
  4766. .RT
  4767. .PP
  4768. The Distributed Single\(hylayer (DS) abstract test method defines the points 
  4769. of control and observation as being at the service boundaries above the 
  4770. (N)\(hyentity under test and above the (N\ \(em\ 1)\(hyService Provider 
  4771. at the SAP remote from the (N)\(hyentity under test. The test events are 
  4772. specified in terms of 
  4773. (N)\(hyASPs above the IUT and (N\ \(em\ 1)\(hyASP\*Us and (N)\(hyPDUs remotely, 
  4774. as shown in 
  4775. Figure\ 6/X.290, Part\ 2. In addition, ALPs may be used as test events.
  4776. Abstractly, lower and upper testers are again considered to observe and 
  4777. control the behaviour at the respective points. The requirements to be 
  4778. met by the test coordination procedures are again defined in the abstract 
  4779. test suites, although the procedures themselves are not. 
  4780. .PP
  4781. For lower layers (1\(hy3) where it may be unrealistic to specify
  4782. observation and control of (N\ \(em\ 1)\(hyASP\*Us, the lower tester observation 
  4783. and 
  4784. control shall be specified in terms of (N)\(hyPDUs and, when necessary,
  4785. changes in the state of the underlying connection.
  4786. .PP
  4787. \fINote\fR \ \(em\ For example, the state of the underlying connection 
  4788. could be changed by setting up a new connection, or resetting or closing 
  4789. an existing 
  4790. connection.
  4791. .PP
  4792. The observation and control to be performed by the lower tester can
  4793. optionally be specified in terms of (N)\(hyASP\*Us where this will reduce
  4794. the size of the test case specification without loss of required
  4795. precision.
  4796. .RT
  4797. .LP
  4798. .rs
  4799. .sp 15P
  4800. .ad r
  4801. \fBFigures 5 et 6/X.290, partie\ 2, (N), p.\fR 
  4802. .sp 1P
  4803. .RT
  4804. .ad b
  4805. .RT
  4806. .LP
  4807. .bp
  4808. .sp 1P
  4809. .LP
  4810. 12.3.3
  4811.     \fIThe coordinated single\(hylayer test method\fR 
  4812. .sp 9p
  4813. .RT
  4814. .PP
  4815. The Coordinated Single\(hylayer (CS) abstract test method is an
  4816. enhanced version of the DS method, using a standardized upper tester and the
  4817. definition of a test management protocol to realize the test coordination
  4818. procedures between the upper and lower testers. The same standardized upper
  4819. tester and test management protocol are not necessarily applicable to all 
  4820. test suites which use the coordinated method. 
  4821. .PP
  4822. Standardized upper testers and test management protocols are
  4823. applicable to a particular standardized abstract test suite for the coordinated 
  4824. test method and may not be applicable to other abstract test suites for 
  4825. the 
  4826. coordinated method.
  4827. .PP
  4828. There is only a single point of control and observation, above the
  4829. (N\ \(em\ 1)\(hyService Provider at the SAP remote from the (N)\(hyentity 
  4830. under test. Test events are specified in terms of (N\ \(em\ 1)\(hyASP\*Us, 
  4831. (N)\(hyPDUs and TM\(hyPDUs, as shown in Figure\ 7/X.290, Part\ 2. 
  4832. .PP
  4833. For lower layers (1\(hy3) where it may be unrealistic to specify
  4834. observation and control of (N\ \(em\ 1)\(hyASP\*Us, the observation and 
  4835. control shall 
  4836. be specified in terms of TM\(hyPDUs, (N)\(hyPDUs and, when necessary, changes
  4837. in the state of the underlying connection.
  4838. .PP
  4839. Concerning the test management protocol:
  4840. .RT
  4841. .LP
  4842.     a)
  4843.     the test management protocol shall be implemented within
  4844. the SUT directly above the abstract service boundary at the top
  4845. of the IUT;
  4846. .LP
  4847.     b)
  4848.     the IUT shall not be required to interpret TM\(hyPDUs, only
  4849. pass them to and from the upper tester;
  4850. .LP
  4851.     c)
  4852.     a test management protocol is only defined for testing a
  4853. particular protocol and so does not need to be independent of
  4854. the underlying protocol;
  4855. .LP
  4856.     d)
  4857.     verdicts on test cases shall not be based on the ability
  4858. of the SUT to exhibit any ASP or parameter of an ASP at the
  4859. upper service boundary of the IUT, since this would contradict
  4860. the definition of the coordinated method in that the upper
  4861. service boundary of the IUT is not a point of control and
  4862. observation in this method. However, it is recommended that
  4863. the test management protocol be defined separately from the
  4864. abstract test suite(s) in order to facilitate the task of the
  4865. implementor of an upper tester. This definition (as with the
  4866. definition of any OSI* protocol defined by ISO or CCITT) can
  4867. refer to the ASPs of its underlying service (i.e.\ the ASPs at
  4868. the upper service boundary of the IUT);
  4869. .LP
  4870.     e)
  4871.     TM\(hyPDUs which correspond to ALPs are optional and there is
  4872. no requirement for the upper tester to support
  4873. them.
  4874. .sp 1P
  4875. .LP
  4876. 12.3.4
  4877.     \fIThe remote single\(hylayer test method\fR 
  4878. .sp 9p
  4879. .RT
  4880. .PP
  4881. The Remote Single\(hylayer (RS) abstract test method defines the point 
  4882. of control and observation as being above the (N\ \(em\ 1)\(hyService Provider 
  4883. at the SAP remote from the (N)\(hyentity under test. The test events are 
  4884. specified in 
  4885. terms of the (N\ \(em\ 1)\(hyASP\*Us and (N)\(hyPDUs remotely, as shown 
  4886. in Figure\ 8/X.290, Part\ 2. In addition, ALPs may be used as test events. 
  4887. Some requirements for 
  4888. test coordination procedures may be implied or informally expressed in the
  4889. abstract test suites, but no assumptions shall be made regarding their
  4890. feasibility or realization.
  4891. .PP
  4892. For the lower layers (1\(hy3) where it is unrealistic to specify
  4893. observation and control of (N\ \(em\ 1)\(hyASP\*Us, the observation and 
  4894. control shall 
  4895. be specified in terms of (N)\(hyPDUs and when necessary the state of the
  4896. underlying connection.
  4897. .PP
  4898. In addition, in order to overcome the lack of specification of
  4899. behaviour above the (N)\(hyentity under test, where necessary the required
  4900. behaviour of the system under test shall be specified in terms of the
  4901. (N\ \(em\ 1)\(hyASP\*Us or (N)\(hyPDUs which need to be observed by the 
  4902. lower tester. 
  4903. This form of implicit specification shall be taken to mean \*Qdo whatever
  4904. is necessary within the system under test in order to provoke this required
  4905. behaviour\*U.
  4906. .PP
  4907. \fINote\fR \ \(em\ Such implicit specification is necessary with this test
  4908. method for any test case which requires an IUT initiated event which cannot 
  4909. be initiated by means of an ALP. Since ALPs may only be defined if the 
  4910. same effect cannot be achieved by ASPs, then any PDU which can be initiated 
  4911. by an ASP needs implicit specification to allow it to be initiated in this 
  4912. test 
  4913. method.
  4914. .PP
  4915. However, it is possible that some of the test cases in the
  4916. abstract test suite cannot be executed (e.g.\ transmission and maintenance of
  4917. busy conditions, transmission of consecutive unacknowledged Data PDUs,\ 
  4918. etc.). In such instances, it is left to the test laboratory and client 
  4919. to negotiate 
  4920. the method by which these tests can be accomplished.
  4921. .bp
  4922. .PP
  4923. Even with such implicit specification of control of the IUT, in
  4924. this method it is possible to specify control but not observation above the
  4925. IUT, except through the use of ALPs. This is a major difference between this
  4926. and the DS and CS test methods.
  4927. .RT
  4928. .LP
  4929. .rs
  4930. .sp 18P
  4931. .ad r
  4932. \fBFigures 7 et 8/X.290, partie\ 2, (N), p.\fR 
  4933. .sp 1P
  4934. .RT
  4935. .ad b
  4936. .RT
  4937. .sp 1P
  4938. .LP
  4939. 12.4
  4940.     \fIMulti\(hylayer test methods for multi\(hylayer IUTs (LM, DM, CM, RM)\fR 
  4941. .sp 9p
  4942. .RT
  4943. .PP
  4944. Multi\(hylayer testing, when the combined allowed behaviour of the
  4945. multi\(hylayer implementation is known, involves testing all the layers of a
  4946. multi\(hylayer IUT as a whole, without controlling or observing any of the
  4947. inter\(hylayer boundaries within the IUT.
  4948. .PP
  4949. In the Local Multi\(hylayer (LM) test method the points of observation
  4950. and control are the service boundaries directly above and below the IUT. The
  4951. test events shall be specified in terms of the (N\dt\u)\(hyASPs and ALPs
  4952. above the IUT and the (N\ \(em\ 1)\(hyASPs and (N) to (N\dt\u)\(hyPDUs below
  4953. the IUT.
  4954. .PP
  4955. In the Distributed Multi\(hylayer (DM) test method the points of
  4956. observation and control are at the service boundary above the IUT and above 
  4957. the (N\ \(em\ 1)\(hyService Provider at the SAP remote from the IUT. The 
  4958. test events 
  4959. shall be specified in terms of the (N\dt\u)\(hyASPs and ALPs above the
  4960. IUT and the (N\ \(em\ 1)\(hyASP\*Us and (N) to (N\dt\u)\(hyPDUs remotely.
  4961. .PP
  4962. In the Coordinated Multi\(hylayer (CM) test method the point of
  4963. observation and control is above the (N\ \(em\ 1)\(hyService Provider at 
  4964. the SAP 
  4965. remote from the IUT. The test events shall be specified in terms of the
  4966. (N\ \(em\ 1)\(hyASP\*Us, the (N) to (N\dt\u)\(hyPDUs and the TM\(hyPDUs. The
  4967. test management protocol shall be designed to operate over the
  4968. (N\dt\u)\(hyService, where (N\dt\u) is the highest layer in the
  4969. IUT.
  4970. .PP
  4971. In the Remote Multi\(hylayer (RM) test method the point of observation
  4972. and control is above the (N\ \(em\ 1)\(hyService Provider at the SAP remote 
  4973. from the 
  4974. IUT. The test events shall be specified in terms of the (N\ \(em\ 1)\(hyASP\*Us 
  4975. and the (N) to (N\dt\u)\(hyPDUs, ALPs and the implicit specification of 
  4976. the 
  4977. control of the SUT behaviour when necessary. Some requirements for test
  4978. coordination procedures may be implied or informally expressed, but no
  4979. assumptions shall be made regarding their feasibility or
  4980. realization.
  4981. .RT
  4982. .sp 1P
  4983. .LP
  4984. 12.5
  4985.     \fISingle\(hylayer testing of multi\(hylayer IUTs or SUTs (Embedded\fR 
  4986. \fImethods)\fR 
  4987. .sp 9p
  4988. .RT
  4989. .PP
  4990. In embedded single\(hylayer test methods testing is specified for a
  4991. single\(hylayer within a multi\(hylayer IUT, including the specification of the
  4992. protocol activity in the layers above the one being tested but without
  4993. specifying control or observation at service boundaries within the multi\(hylayer 
  4994. IUT. Thus in a multi\(hylayer IUT from layer (N) to (N\dt\u), 
  4995. abstract test cases for testing layer\ (N\di\u) shall include the
  4996. specification of the PDUs in layers\ (N\di\u+1) to (N\dt\u) as well as
  4997. those in layer\ (N\di\u).
  4998. .bp
  4999. .PP
  5000. The Local Single\(hylayer Embedded (LSE) test method uses the same points 
  5001. of control and observation as the LM test method for the same set of layers. 
  5002. The test events shall also be specified in the same terms as for the LM test
  5003. method. The difference is that the LSE test method concentrates on a
  5004. single\(hylayer at a time, whereas the LM test method tests the multi\(hylayer 
  5005. IUT as a whole. 
  5006. .PP
  5007. In the Distributed Single\(hylayer Embedded (DSE) test method for layer 
  5008. (N\di\u) within a multi\(hylayer IUT from layer (N) to (N\dt\u) the 
  5009. points of observation and control are at the service boundary above the 
  5010. IUT and above the (N\di\u\ \(em\ 1)\(hyService Provider at the SAP remote 
  5011. from the IUT, as 
  5012. illustrated in Figure\ 9a)/X.290, Part\ 2. The test events shall be specified 
  5013. in terms of (N\dt\u)\(hyASPs and ALPs above the IUT and (N\di\u\ \(em\ 
  5014. 1)\(hyASP\*Us 
  5015. and (N\di\u) to (N\dt\u)\(hyPDUs remotely.
  5016. .PP
  5017. \fINote\fR \ \(em\ For the top layer in the multi\(hylayer IUT, (N\dt\u),
  5018. this method is the same as the DS test method.
  5019. .PP
  5020. The Coordinated Single\(hylayer Embedded (CSE) test method uses features 
  5021. of both the CM and DSE test methods. The test events shall be specified 
  5022. in 
  5023. terms of (N\di\u\ \(em\ 1)\(hyASP\*Us, (N\di\u) to (N\dt\u)\(hyPDUs and
  5024. TM\(hyPDUs and the test management protocol shall be designed to operate over
  5025. the (N\dt\u)\(hyService. This is illustrated in Figure\ 9b)/X.290,
  5026. Part\ 2.
  5027. .PP
  5028. The Remote Single\(hylayer Embedded (RSE) test method uses the same
  5029. point of control and observation as the RS test method for the same layer,
  5030. but differs from the RS test method in that (N\di\u+1) to (N\dt\u)\(hyPDUs
  5031. shall be specified in test cases for layer (N\di\u).
  5032. .PP
  5033. Successive use of a single\(hylayer embedded test method (from layer
  5034. (N) to (N\dt\u)) is called incremental testing of a
  5035. multi\(hylayer IUT.
  5036. .PP
  5037. The DSE/CSE/RSE methods are defined for a single layer under test
  5038. in a multi\(hylayer IUT. This does not mean that there cannot be accessible
  5039. service boundaries within the multi\(hylayer IUT, just that no such boundaries 
  5040. are used in the test methods. Thus, all layers between the layer under 
  5041. test and the highest layer for which PDUs are expressed as test events 
  5042. in the abstract test suite shall be regarded as being part of the multi\(hylayer 
  5043. IUT. 
  5044. .PP
  5045. \fINote\fR \ \(em\ DME/CME/RME test methods could theoretically be defined to
  5046. test multiple layers as a whole within a larger multi\(hylayer IUT, but 
  5047. in order to avoid excess complexity, they are not detailed in this 
  5048. Recommendation.
  5049. .RT
  5050. .LP
  5051. .rs
  5052. .sp 25P
  5053. .ad r
  5054. \fBFigure 9/X.290, partie\ 2, (N), p.\fR 
  5055. .sp 1P
  5056. .RT
  5057. .ad b
  5058. .RT
  5059. .LP
  5060. .bp
  5061. .sp 1P
  5062. .LP
  5063. 12.6
  5064.     \fIRelay test methods\fR 
  5065. .sp 9p
  5066. .RT
  5067. .PP
  5068. There are two abstract test methods for relay system
  5069. testing:
  5070. .RT
  5071. .LP
  5072.     a)
  5073.     the loop\(hyback test method (YL): used for testing a relay
  5074. system from one subnetwork.
  5075. .LP
  5076.     This test method is illustrated in Figure\ 10/X.290,
  5077. Part\ 2.
  5078. .LP
  5079.     For this test method there are two points of observation and
  5080. control on one subnetwork at SAPs remote from the (N)\(hyRelay.
  5081. For connection\(hyoriented protocols, it requires that the two test
  5082. connections are looped together on the far side of the
  5083. (N)\(hyRelay, but it is not specified whether this looping is
  5084. performed within the (N)\(hyRelay or in the second subnetwork. For
  5085. connectionless protocols, it requires that the PDUs are looped
  5086. back within the second subnetwork and addressed to return to the
  5087. second point of observation and control.
  5088. .LP
  5089.     b)
  5090.     the transverse test method (YT): used for testing a relay
  5091. system from two subnetworks.
  5092. .LP
  5093.     This test method is illustrated in Figure\ 11/X.290,
  5094. Part\ 2.
  5095. .LP
  5096.     In this test method there are two points of observation and
  5097. control, one on each subnetwork, at SAPs remote from the
  5098. (N)\(hyRelay.
  5099. .LP
  5100. .rs
  5101. .sp 16P
  5102. .ad r
  5103. \fBFigure 10/X.290, partie\ 2, (N), p.\fR 
  5104. .sp 1P
  5105. .RT
  5106. .ad b
  5107. .RT
  5108. .LP
  5109. .rs
  5110. .sp 16P
  5111. .ad r
  5112. \fBFigure 11/X.290, partie\ 2, (N), p.\fR 
  5113. .sp 1P
  5114. .RT
  5115. .ad b
  5116. .RT
  5117. .LP
  5118. .bp
  5119. .sp 2P
  5120. .LP
  5121. 12.7
  5122.     \fIChoice of test method\fR 
  5123. .sp 1P
  5124. .RT
  5125. .sp 1P
  5126. .LP
  5127. 12.7.1
  5128.     \fIIntroduction\fR 
  5129. .sp 9p
  5130. .RT
  5131. .PP
  5132. Before an abstract test suite can be defined, it is necessary to
  5133. study all the environments in which the protocol is likely to be tested and
  5134. establish accordingly the abstract test method(s) to be used for the production 
  5135. of one or more abstract test suites. 
  5136. .PP
  5137. Abstract test suite specifiers shall place a requirement in the
  5138. abstract test suite Recommendation* defining which abstract test method(s)
  5139. shall be supported as a minimum by any organization claiming to provide a
  5140. comprehensive testing service for the protocol(s) in question.
  5141. .RT
  5142. .sp 1P
  5143. .LP
  5144. 12.7.2
  5145.     \fIIUT environments\fR 
  5146. .sp 9p
  5147. .RT
  5148. .PP
  5149. There is a relation between the test methods and the
  5150. configurations of the real open systems to be tested.
  5151. .PP
  5152. Section 7.2 Part 1 of this Recommendation gives a full account of
  5153. the classification of systems and IUTs.
  5154. .PP
  5155. When choosing a test method, the test suite specifiers should
  5156. identify, if they have not already done so, whether the test suites they 
  5157. plan to produce are for IUTs which 
  5158. .RT
  5159. .LP
  5160.     a)
  5161.     are single or multi\(hylayer;
  5162. .LP
  5163.     b)
  5164.     belong to end or relay systems;
  5165. .LP
  5166.     c)
  5167.     belong to complete or partial systems;
  5168. .LP
  5169.     d)
  5170.     belong to fully open or mixed systems;
  5171. .LP
  5172.     e)
  5173.     have service boundaries accessible or not;
  5174. .LP
  5175.     f
  5176. )
  5177.     are special purpose (i.e. to be used by a single
  5178. application) or general purpose (i.e.\ to be used by several
  5179. applications).
  5180. .sp 1P
  5181. .LP
  5182. 12.7.3
  5183.     \fIApplicability of the abstract test methods\fR 
  5184. .sp 9p
  5185. .RT
  5186. .PP
  5187. The possibility of developing an abstract test suite for a given
  5188. abstract test method will depend on the protocol(s) being considered, together 
  5189. with the results of the study described in \(sc\ 12.7.2. This applies to 
  5190. the possibility of developing test suites for a given combination of methods
  5191. (e.g.\ incremental) or a given variant of a method (e.g.\ embedded).
  5192. .PP
  5193. Some considerations concerning the applicability of the methods to
  5194. different layers are discussed in Appendix\ I of Part\ 1 of this
  5195. Recommendation.
  5196. .PP
  5197. One or more appropriate abstract test methods shall be selected
  5198. for the protocol being considered.
  5199. .PP
  5200. Priorities should be assigned to the various test methods which
  5201. have been identified, according to the configurations which are most likely 
  5202. to be found in real systems. 
  5203. .RT
  5204. .sp 1P
  5205. .LP
  5206. 12.7.4
  5207.     \fIIllustrative examples\fR 
  5208. .sp 9p
  5209. .RT
  5210. .PP
  5211. Appendix\ III provides an illustrative example of the choice of
  5212. abstract test methods for given protocols.
  5213. .RT
  5214. .sp 1P
  5215. .LP
  5216. 12.8
  5217.     \fITest coordination procedures\fR 
  5218. .sp 9p
  5219. .RT
  5220. .PP
  5221. For effective and reliable execution of conformance tests, some set of 
  5222. rules is required for the coordination of the test process between the 
  5223. lower tester and the upper tester. The general objective of these rules 
  5224. is to enable the lower tester to control remotely the operation of the 
  5225. upper tester or vice versa, in ways necessary to run the test suite selected 
  5226. for the IUT. 
  5227. .PP
  5228. These rules lead to the development of test coordination procedures to 
  5229. achieve the synchronization between the lower tester and the upper tester 
  5230. and the management of information exchanged during the testing process. 
  5231. The details and how these effects are achieved are closely related to the 
  5232. characteristics of the SUT, as well as the external test methods. 
  5233. .PP
  5234. For each abstract test suite using the coordinated, distributed or
  5235. local test methods, a standard set of test coordination procedures should be
  5236. developed. This is because those procedures depend on the functionality 
  5237. of the upper tester and definitions of test cases. 
  5238. .bp
  5239. .PP
  5240. In the case of the coordinated test methods (CS, CSE, CM) the test
  5241. coordination procedures are realized by the standardization of a test
  5242. management protocol. The test management protocol needs to be able to convey
  5243. requests to the IUT to achieve the effect of a service primitive or ALP 
  5244. and to convey back to the lower tester the record of observations of effects 
  5245. equivalent to the occurrence of service primitives or ALPs. The upper tester
  5246. should be an implementation of the test management protocol. It will be
  5247. necessary to add test cases to the abstract test suite for the purpose of
  5248. testing that the upper tester conforms to the requirements of the test
  5249. management protocol specification. Such test cases do not contribute to the
  5250. conformance assessment of the IUT.
  5251. .PP
  5252. When defining test cases for the local and distributed test methods, the 
  5253. test suite specifier shall record any constraints on the upper tester 
  5254. and/or test coordination procedures which may be necessary.
  5255. .RT
  5256. .LP
  5257. \fB13\fR     \fBSpecification of abstract test suites\fR 
  5258. .sp 1P
  5259. .RT
  5260. .sp 2P
  5261. .LP
  5262. 13.1
  5263.     \fITest cases\fR 
  5264. .sp 1P
  5265. .RT
  5266. .PP
  5267. 13.1.1
  5268. The abstract test suite specifier shall select an appropriate standardized 
  5269. notation in which to define the abstract test cases. The Tree and Tabular 
  5270. Combined Notation (TTCN), defined in Annex\ D, is defined for this 
  5271. purpose.
  5272. .sp 9p
  5273. .RT
  5274. .PP
  5275. 13.1.2
  5276. Once the test notation and test method have been chosen,
  5277. then the generic test cases can be expanded into abstract test cases. There 
  5278. are two main kinds of change required to convert a generic test case into 
  5279. an 
  5280. abstract test case. The first is to express the test body in terms of control 
  5281. and observation required by the test method, and, if relevant, include 
  5282. a 
  5283. description of the synchronization needed between upper and lower
  5284. testers. The second kind of change is to specify the preamble and
  5285. postamble.
  5286. .sp 9p
  5287. .RT
  5288. .PP
  5289. 13.1.3
  5290. Specification of preambles and postambles may result in more
  5291. than one test step for each. The preamble shall start in a stable state and
  5292. progress to the desired state. Conversely, the postamble shall progress from
  5293. the final state of the test body to a stable state. A small number of stable
  5294. states shall be defined for the protocol concerned, always containing as a
  5295. minimum the \*Qidle\*U state. Each abstract test case shall be capable 
  5296. of being run on its own and shall therefore include test steps to start 
  5297. the preamble from 
  5298. the \*Qidle\*U state and to end the postamble in the \*Qidle\*U state.
  5299. .sp 9p
  5300. .RT
  5301. .PP
  5302. However, other stable starting and final states for an abstract
  5303. test case can be useful when efficient concatenation of abstract test cases 
  5304. is required. 
  5305. .PP
  5306. Furthermore, in designing the test step structure within the abstract test 
  5307. cases, the test suite specifier can benefit from using the same test steps 
  5308. in several abstract test cases. 
  5309. .RT
  5310. .PP
  5311. 13.1.4
  5312. In converting from generic test cases to abstract test
  5313. cases, the test suite specifier shall ensure that the initial state for the
  5314. test body is preserved, the pass paths through the test body are preserved 
  5315. and the assignment of verdicts to outcomes remains consistent. 
  5316. .sp 9p
  5317. .RT
  5318. .PP
  5319. In order to maintain consistency, the following conditional
  5320. requirements apply when assigning verdicts to outcomes:
  5321. .LP
  5322.     a)
  5323.     if the behaviour of the preamble and the postamble are
  5324. valid then the verdict assigned to a particular outcome shall be
  5325. the same as that assigned to the corresponding outcome in the
  5326. generic test case;
  5327. .LP
  5328.     b)
  5329.     if the preamble results in the initial state of the test
  5330. body not being reached, although there is no invalid behaviour,
  5331. then the verdict shall be inconclusive;
  5332. .LP
  5333.     c)
  5334.     if the preamble results in the initial state of the test
  5335. body not being reached, because of invalid behaviour, then the
  5336. verdict shall be \*Qfail but test purpose inconclusive\*U (\*Qfail
  5337. type\ 3\*U);
  5338. .LP
  5339.     d)
  5340.     if the postamble exhibits invalid behaviour and the
  5341. generic test case (or test body) verdict is \*Qpass\*U or
  5342. \*Qinconclusive\*U, then the verdict shall be \*Qfail but test purpose
  5343. passed\*U (\*Qfail type\ 2\*U) or \*Qfail but test purpose inconclusive\*U
  5344. (\*Qfail type\ 3\*U), respectively;
  5345. .LP
  5346.     e)
  5347.     if the generic test case (or test body) verdict is \*Qfail\*U
  5348. then invalid behaviour in the postamble shall not
  5349. change the verdict (\*Qfail type\ 1\*U).
  5350. .bp
  5351. .PP
  5352. 13.1.5
  5353. The test suite specifier shall also ensure that each
  5354. abstract test case explicitly identifies all the outcomes assigned the 
  5355. verdict \*Qpass\*U and identifies or categorizes all the remaining foreseen 
  5356. outcomes, 
  5357. assigning to each individual outcome or category a verdict \*Qfail\*U or
  5358. \*Qinconclusive\*U. All unforeseen outcomes in the test body shall be assigned
  5359. either:
  5360. .sp 9p
  5361. .RT
  5362. .LP
  5363.     a)
  5364.     the verdict \*Qfail\*U; or
  5365. .LP
  5366.     b)
  5367.     the verdict \*Qinconclusive\*U.
  5368. .PP
  5369. The test suite specifier shall ensure that the application of a) or b) 
  5370. is consistent throughout the abstract test suite. If\ a) is chosen, then 
  5371. any unforeseen outcome in the preamble shall be assigned the verdict \*Qfail 
  5372. but test purpose inconclusive\*U (\*Qfail type\ 3\*U), and any unforeseen 
  5373. outcome in the postamble shall be treated as a protocol violation, leading 
  5374. to the appropriate type of fail verdict. 
  5375. .PP
  5376. If b) is chosen, then any unforeseen outcome in the preamble shall
  5377. be assigned the verdict \*Qfail but test purpose inconclusive\*U (\*Qfail 
  5378. type\ 3\*U), and any unforeseen outcome in the postamble shall be assigned 
  5379. the appropriate type of fail verdict. 
  5380. .RT
  5381. .sp 1P
  5382. .LP
  5383. 13.2
  5384.     \fITest suites\fR 
  5385. .sp 9p
  5386. .RT
  5387. .PP
  5388. An abstract test suite specification comprises a set of test cases and 
  5389. test steps. Preceding the test cases themselves shall be the following 
  5390. information:
  5391. .RT
  5392. .LP
  5393.     a)
  5394.     abstract test suite name, date of origin and version
  5395. number;
  5396. .LP
  5397.     b)
  5398.     names (and version numbers) of the protocol
  5399. Recommendation(s)* for which test cases are provided;
  5400. .LP
  5401.     c)
  5402.     names (and version numbers) of the service
  5403. Recommendation(s)* whose primitives are specified as
  5404. being observed;
  5405. .LP
  5406.     d)
  5407.     name (and version number) of the Recommendation*
  5408. defining the test notation, or a reference to an annex for the
  5409. same if it is not standardized elsewhere;
  5410. .LP
  5411.     e)
  5412.     name of target test method;
  5413. .LP
  5414.     f
  5415. )
  5416.     description of the coverage of the test suite; for
  5417. example, the functional subsets of the protocol
  5418. Recommendation(s)* that are tested;
  5419. .LP
  5420.     g)
  5421.     description of the structure of the test suite, in terms
  5422. of test groups and their relationship to the protocol
  5423. Recommendation(s)*;
  5424. .LP
  5425.     h)
  5426.     description of the test coordination procedures (if
  5427. applicable in the test method);
  5428. .LP
  5429.     i)
  5430.     statement of which test cases are optional and which
  5431. mandatory for conformance to the abstract test suite
  5432. Recommendation*;
  5433. .LP
  5434.     j)
  5435.     information to assist the test realizer and test laboratory
  5436. in their use of the abstract test suite Recommendation* (see
  5437. \(sc\ 14).
  5438. .sp 2P
  5439. .LP
  5440. \fB14\fR     \fBUse of an abstract test suite specification\fR 
  5441. .sp 1P
  5442. .RT
  5443. .PP
  5444. The abstract test suite specifier shall provide information in the abstract 
  5445. test suite Recommendation* to assist the test realizer and 
  5446. test laboratory in their uses of the test suite. This information shall
  5447. include, but is not limited to, the following:
  5448. .RT
  5449. .LP
  5450.     a)
  5451.     a mapping of the abstract test cases to the PICS proforma
  5452. entries to determine whether or not each abstract test case is
  5453. to be selected for the particular IUT; the mapping should be
  5454. specified  in a suitable notation for Boolean
  5455. expressions;
  5456. .LP
  5457.     b)
  5458.     a mapping of the abstract test cases to the PIXIT proforma
  5459. entries, to the extent that they are known by the abstract test
  5460. suite specifier, to parameterize the test suite for the
  5461. particular IUT and to determine which selected test cases cannot
  5462. be run with the particular IUT.
  5463. .LP
  5464.     The test suite specifier shall define a partial PIXIT proforma.
  5465. This shall contain a list of all the ALPs used in the test suite (or test
  5466. management protocol) and a list of all parameters for which the test suite
  5467. requires values. If any of the required parameter values will be found 
  5468. in the PICS, the PIXIT proforma entry for each such parameter shall reference 
  5469. the 
  5470. corresponding entry in the PICS proforma;
  5471. .LP
  5472.     \fINote\fR \ \(em\ Other aspects of the PIXIT proforma are for further
  5473. study;
  5474. .bp
  5475. .LP
  5476.     c)
  5477.     a list of the abstract test cases in the order that shall
  5478. be used in the Protocol Conformance Test Report (PCTR), together
  5479. with any information which shall be preserved in the PCTR on the
  5480. status of each test case; this is a contribution to the
  5481. development of a PCTR proforma;
  5482. .LP
  5483.     d)
  5484.     any restrictions that there may be on the order in which
  5485. the test cases may be executed;
  5486. .LP
  5487.     e)
  5488.     reference to the description of the test coordination
  5489. procedures (if applicable in the chosen test method);
  5490. .LP
  5491.     f
  5492. )
  5493.     any necessary timing information.
  5494. .sp 2P
  5495. .LP
  5496. \fB15\fR     \fBTest suite maintenance\fR 
  5497. .sp 1P
  5498. .RT
  5499. .PP
  5500. Once an abstract test suite has been specified and is in use, it
  5501. can be expected that errors and omissions in it will be detected by those 
  5502. who are using the test suite. The abstract test suite specifier shall in 
  5503. such 
  5504. circumstances progress the updating of the test suite via the relevant rapid
  5505. amendment procedures.
  5506. .PP
  5507. In addition, from time\(hyto\(hytime, changes will be made to the protocol 
  5508. Recommendation(s)* to which the test suite relates. The abstract test suite 
  5509. specifier shall ensure that the test suite is updated as soon as possible 
  5510. after changes to the relevant protocol Recommendation* have been ratified. 
  5511. \v'6p'
  5512. .RT
  5513. .ce 1000
  5514. ANNEX\ A
  5515. .ce 0
  5516. .ce 1000
  5517. (to Recommendation X.290, Part 1)
  5518. .sp 9p
  5519. .RT
  5520. .ce 0
  5521. .ce 1000
  5522. \fR \fBOptions\fR 
  5523. .sp 1P
  5524. .RT
  5525. .ce 0
  5526. .PP
  5527. A.1
  5528. Options are those items in a Recommendation* for which the
  5529. implementor may make a choice regarding the item to suit the implementation.
  5530. .sp 1P
  5531. .RT
  5532. .PP
  5533. A.2
  5534. Such a choice is not truly free. There are requirements which
  5535. specify the conditions under which the option applies and the limitations of
  5536. the choice.
  5537. .sp 9p
  5538. .RT
  5539. .PP
  5540. Conversely, there may be mandatory or conditional requirements, or prohibitions, 
  5541. in a Recommendation* which are dependent on the choice made or on a combination 
  5542. of the choices already made. 
  5543. .PP
  5544. A.3
  5545. The following are examples of options and associated
  5546. requirements; the list is not exhaustive:
  5547. .sp 9p
  5548. .RT
  5549. .LP
  5550.     a)
  5551.     \*QBoolean\*U options: the option is \*Qdo or do not do\*U; the
  5552. requirement is \*Qif do, then do as specified.\*U
  5553. .LP
  5554.     b)
  5555.     Mutually exclusive options: the requirement is to do just
  5556. one of \fIn\fR \ actions, the option is which of them to do.
  5557. .LP
  5558.     c)
  5559.     Selectable options: the option is to do any \fIm\fR \| out of \fIn\fR \|
  5560. actions, with a requirement to do at least one
  5561. action (1\ \(=\ \fIm\fR \ \(=\ \fIn\fR and \fIn\fR \ \(>="\ 2).
  5562. .PP
  5563. A.4
  5564. Options may apply to anything within the scope of a
  5565. Recommendation* (e.g.\ static or dynamic aspects, use or provision of a 
  5566. service, actions to be taken, presence/absence or form of parameters,\ 
  5567. etc.). 
  5568. .sp 9p
  5569. .RT
  5570. .PP
  5571. A.5
  5572. Another type of distinction is between service\(hyuser options and service\(hyprovider 
  5573. options. 
  5574. .sp 9p
  5575. .RT
  5576. .PP
  5577. A.6
  5578. In a wider context, the choice will be determined by conditions which lie 
  5579. outside the scope of the Recommendation* (e.g.\ other 
  5580. Recommendations* which apply to the implementation, the protocols used
  5581. in the (N+1) and (N\ \(em\ 1) layers, the intended application, conditions of
  5582. procurement, target price for the implementation,\ etc.). However, these have
  5583. no bearing on conformance to the Recommendation* in which the option
  5584. appears.
  5585. .sp 9p
  5586. .RT
  5587. .LP
  5588. .bp
  5589.